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viii  Development  of  the  DCW 


Chapter  1.  Project  Summary 


1.1  Introduction 

The  Digital  Chart  of  the  World  (DCW)  is  a  topologically  structured  global  vector  database 
developed  by  Environmental  Systems  Research  Institute,  Inc.  (ESRI)  for  the  Defense  Mapping 
Agency  (DMA)  to  support  global  scientific  and  military  analysis.  Completed  in  1992  and  now 
available  for  public  purchase  (Appendix  A),  it  contains  1.7  gigabytes  of  topological  data,  the 
largest  spatial  database  ever  designed  specifically  for  public  dissemination  on  the  Compact 
Disc-Read-Only  Memory  (CD-ROM)  medium.  The  database  stores  georelational  attributes 
organized  into  seventeen  thematic  layers  designed  for  Geographic  Information  System  (GIS) 
applications;  the  layers  include  political  boundaries,  populated  places,  road  and  railroad 
networks,  land  cover,  drainage,  elevation  contours,  ocean  features,  and  data  quality.  The 
source  data  were  276  charts  in  the  Operational  Navigation  Chart  (ONC)  and  (for  Antarctica)  the 
Jet  Navigation  Chart  (JNC)  series. 

Even  though  the  DCW  database  makes  a  significant  contribution  to  global  military  and 
scientific  analysis  by  itself,  the  most  significant  outcome  of  the  DCW  project  was  the 
development  of  a  generic,  machine-independent  format  for  GIS  data  that  allows  data  prepared 
in  accordance  with  it  to  be  used  by  diverse  software  systems.  Known  as  Vector  Product 
Format  (VPF),  this  data  format  was  implemented  in  the  DCW  database  and  will  be  used  for  the 
vector  data  products  developed  by  DMA  (and  potentially  other  organizations)  in  the  future. 
These  products  will  allow  DMA's  data  users — the  U.S.  Department  of  Defense,  mapping 
organizations  in  NATO-member  countries,  the  U.S.  intelligence  community,  and  the 
International  Hydrographic  Community — to  establish  applications  software  to  read  data  from  a 
common  format  Through  promotion  of  a  common  understanding  of  spatial  vector  data,  VPF 
thus  promotes  interoperability  between  diverse  data  users. 

As  a  generic  data  format,  VPF  has  been  incoiporated  into  the  Digital  Geographic  Information 
Exchange  Standard  (DIGEST)  by  an  international  standards  committee  known  as  the  Digital 
Geographic  Information  Working  Group  (DGIWG),  which  includes  representatives  from 
thirteen  countries  in  Europe  and  North  America.  Under  DIGEST,  VPF  is  known  as  Vector 
Relational  Format  (VRF). 

The  DCW  project  was  a  multinational  effort  with  participation  by  military  mapping 
organizations  from  Australia,  Canada,  the  United  Kingdom,  and  the  United  States  and  civilian 
mapping  organizations  from  Canada  and  the  United  States.  ESRI  organized  and  coordinated 
periodic  design  reviews  as  part  of  the  project.  During  these  meetings,  ESRI  presented  the 
results  of  the  most  recent  prototyping  activity  and  discussed  the  current  status  of  the  design. 
These  meetings  also  provided  a  forum  for  the  open  discussion  and  technical  review  of  ESRI's 
work.  In  addition  to  DMA  and  the  participating  international  organizations,  others  in 
attendance  included  representatives  from  United  States  Army  Corps  of  Engineers  (USACE) 
laboratories,  the  Naval  Research  Laboratory  (NRL),  the  Naval  Ocean  Systems  Center 
(NOSC),  the  National  Oceanographic  and  Atmospheric  Administration  (NOAA),  U.S. 
intelligence  agencies,  and  the  United  States  Geological  Survey  (USGS). 
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In  addition  to  the  development  of  a  standai .  data  format  and  the  production  of  the  DCW 
database,  the  DCW  project  resulted  in  the  development  of  a  standard  production  process  for  the 
creation  and  subsequent  maintenance  of  the  DCW  database  and  the  development  of  an 
applications  software  package  (known  as  VPFVIEW)  for  the  display  and  demonstration  of  the 
DCW  and  other  VPF  databases.  As  another  outgrowth  of  the  project,  in  late  1991  ESR1  began 
to  develop  two  additional  VPF  database  prototypes — the  Digital  Nautical  Chan  (DNC)  and  the 
Vector  Sman  Map  (VSM). 


1.2  Chronological  Overview 

For  purposes  of  this  report,  the  DCW  project  can  be  considered  to  have  three  phases:  DCW 
design  and  prototyping,  DCW  production,  and  the  development  of  two  additional  VPF- 
compliant  prototypes. 

During  the  design  and  prototyping  phase  (October  1989  to  January  1991),  DCW  product 
requirements  were  refined  and  tested  in  a  series  of  prototypes;  the  final  design  decisions  were 
embodied  in  the  DCW  product  specification  (see  Appendix  B).  The  prototypes  also  helped 
establish  and  refine  the  DCW  production  methodology,  the  VPFVIEW  software,  and  the  VPF 
standard. 

During  the  production  phase  (September  1990  to  April  1992),  the  full-scale  production  of  the 
DCW  took  place;  production  was  followed  by  product  duplication  and  distribution  (May  1992 
to  August  1992). 

During  the  third  phase  (January  1992  through  December  1992),  ESRI  is  prototyping  the  VSM 
and  DNC,  two  additional  DMA  product  series  that  have  been  prepared  in  accordance  with 
VPF. 


1.3  Phase  I— Design  and  Prototyping 

1.3.1  Prototype  Development 

Four  DCW  database  prototypes  were  designed  and  produced  for  the  purpose  of  evaluating 
design  decisions,  evaluating  the  VPFVIEW  functions,  establishing  database  automation 
procedures,  and  implementing  VPF.  The  exercise  of  the  prototypes,  and  the  ideas  and 
information  generated  by  their  review,  were  intended  to  allow  the  incremental  development  of 
the  design  of  the  DCW.  Each  of  these  prototypes  was  itself  an  interim  product,  which,  when 
disseminated  to  the  various  participants,  provided  an  opportunity  for  feedback  with  respect  to 
product  content,  design,  and  application  programs. 

Prototype  1  enveloped  from  October  1989  to  December  1989)  was  used  to  test  and 
demonstrate  a  mockup  of  the  DCW  for  a  small  portion  of  ONC  G-18.  PC  ARC/INFO 
software  was  used  for  Prototype  1  because  it  provided  ready-made  display  and  query 
capabilities.  Applications  software  was  written  using  the  Simple  Macro  Language  to 
demonstrate  the  basic  user  interface  and  planned  functional  capabilities. 
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Prototype  2  (developed  from  January  1990  to  April  1990)  implemented  the  design  concept 
developed  for  Prototype  1.  The  software  represented  the  first  prototype  of  the  VPFVIEW 
software.  The  database  encompassed  a  larger  portion  of  ONC  G-18,  small  portions  of  two 
NOAA  charts  for  Hampton  Roads,  Virginia,  and  a  small  portion  of  the  Killeen,  Texas 
l:50,000-scale  topographic  map.  These  large-scale  data  sources  were  used  for  the  database  to 
begin  to  examine  the  ability  of  the  software  to  handle  large-scale  data.  Comments  on  the  first 
prototype  and  additional  information  from  the  participants  in  the  project  were  incorporated  in 
this  prototype,  which  focused  primarily  on  the  conceptual  designs  for  the  DCW  and  the 
software. 

Prototype  3  (developed  from  May  1990  to  August  1990)  fully  implemented  the  VPFVIEW 
software  functions  presented  in  the  second  prototype.  Its  development  also  entailed  the 
establishment  of  standard  database  production  procedures.  Prototype  3  was  the  first  prototype 
for  which  data  were  structured  according  to  VPF  and  stored  on  CD-ROM.  However,  the  VPF 
standard  continued  to  evolve  beyond  this  point.  The  data  sets  for  this  prototype  included 
ONCs  G-18  and  N-13,  JNC  120,  the  Killeen  topographic  map,  and  the  nautical  charts  for 
Hampton  Roads  and  Harwich,  U.K. 

Prototype  4  (developed  from  July  1990  to  December  1990)  fully  implemented  the  ideas  for 
database  redesign  and  the  new  VPFVIEW  functions  added  after  the  comments  from  the  DCW 
participants  were  considered.  A  complete  set  of  Standard  Operating  Procedures  (SOPs)  for  the 
DCW  database  production  was  developed,  since  this  prototype  served  as  a  production  dry  run. 
This  prototype  was  the  first  to  contain  adjacent  map  sheets  in  the  database  (ONCs  E-l,  F-l, 
G-l,  and  G-2),  and  so  its  production  entailed  the  development  of  preliminary  production  sheets 
for  edge  matching.  Submission  of  this  prototype  to  DMA  in  September  1990  marked  the 
beginning  point  for  full-scale  production  of  the  DCW  database. 

1.3.2  Special  Studies 

Several  special  studies  were  conducted  early  in  the  development  of  the  DCW  database.  These 
studies  were  made  to  determine  the  best  way  to  implement  the  storage  of  aeronautical 
information,  storage  of  elevation  data,  data  partitioning  (tiling),  indexing  (how  to  set  the  data 
up  for  rapid  access  and  retrieval),  geographic  organization  (which  portions  of  the  world  to 
include  on  each  CD-ROM),  symbolization,  and  error  analysis.  The  results  of  these  studies 
were  applied  to  Prototype  4. 

1.3.3  Standard  Development 

Vector  product  format  (which  was  at  first  called  the  Vector  Product  Standard  or  VPS) 
underwent  development  throughout  the  prototyping  period.  The  primary  objective  of  the 
development  was  to  ensure  that  VPF  could  be  used  not  only  for  the  DCW,  but  also  for  other 
digital  data  products  being  developed  within  DMA.  The  development  of  VPF  represented  a 
significant  portion  of  the  effort  devoted  to  the  DCW  project  as  a  whole. 

A  generic,  product- neutral,  hardware-independent  georelational  data  model,  VPF  is  designed  to 
support  direct  usage  by  GIS  software;  it  is  not  a  data  exchange  standard.  VPFs  characteristics 
enable  it  to  support  seamless  databases,  to  model  different  topologies  and  topological  levels,  to 
support  feature-  and  coverage-based  designs,  and  to  store  metadata  (information  about  the 
database  itself).  It  has  been  adopted  as  part  of  a  family  of  standards  known  as  DIGEST. 
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Within  this  standard,  VPF  defines  the  rektional  format  for  vector-based  products,  and  is  thus 
called  Vector  Relational  Format  (VRF);  the  content  of  VPF  and  VRF  is  identical. 

A  training  plan  has  been  developed  to  transfer  VPF  technology  to  DMA.  The  plan  is  described 
briefly  in  Appendix  C. 

An  additional  objective  of  the  DCW  prototyping  phase — as  originally  defined  in  the  DCW 
Statement  of  Work  (SOW) — was  to  develop  applications  software  that  would  enable  the  user  to 
display  the  DCW  database.  However,  during  the  prototyping  period,  the  objective  for  the 
software  expanded  to  include  the  generic  demonstration  of  VPF  databases.  Software 
functionality  also  expanded  as  the  result  of  prototype  review;  the  final  VPFVEEW  functions 
include  feature  selection,  graphics  display  and  report,  text  report,  file  archive,  operations  on  the 
DOS  system,  spatial  query,  adaptive  menuing,  map  distance  measuring  functions,  and  others. 

The  VPFVIEW-DOS  software  released  with  the  DCW  database  was  designed  to  be  used  on 
PC-class  computers.  A  UNIX -based  version  known  as  VPFVIEW— UNIX  was  requested  by 
DMA  and  will  be  complete  by  December  1992. 

The  application  of  VPFVIEW  to  other  VPF  databases  such  as  the  DNC  and  VSM  is  currently 
being  worked  on  at  ESRI  (see  the  description  of  Phase  in  below).  These  projects  are 
continuing  to  test  the  design  of  VPF  and  to  support  its  widest  possible  applicability  to  other 
digital  vector  data. 


1.4  Phase  II— DCW  Database  Production  and  Quality 
Assurance 

1.4.1  Production  Procedures 

Database  production  was  the  most  time-consuming  and  labor-intensive  portion  of  the  DCW 
project,  it  involved  the  automation  of  276  ONC  ami  JNC  source  maps  to  create  a  topologically 
structured,  geocoded,  vector  database.  Automation  was  followed  by  conversion  to  VPF  data 
structure  and  storage  on  CD-ROMs  for  public  dissemination. 

One  of  the  requirements  of  DCW  production  was  that  it  proceed  according  to  standard 
operating  procedures  to  be  established  during  the  project.  Guided  by  the  standards  required  for 
the  final  product,  those  responsible  for  production  focused  on  creating  production  procedures 
that  would  use  both  proven  methodologies  and  new  procedures  to  ensure  production  efficiency 
and  a  high  level  of  quality  in  the  product  In  September  1990,  after  detailed  preliminary 
production  procedures  were  developed  for  Prototypes  3  and  4,  full-scale  production  began. 

The  production  period  consisted  of  ramp-up,  full  production,  and  ramp-down  periods.  During 
the  period  of  full  production,  nineteen  Sun  SPARC  workstations  were  utilized  on  a  two-shift 
basis  to  conduct  most  production  operations.  Production  was  completed  in  April  of  1992. 

During  product  packaging  (May  1992  to  August  1992),  the  four  preliminary  DCW  CD-ROMs 
developed  during  the  production  process  were  duplicated  (10, (XX)  copies  of  each),  packaged, 
and  shipped  along  with  the  VPFVIEW  software  and  user  documentation  to  government 
distribution  points  in  the  United  States,  the  United  Kingdom,  Canada,  and  Australia  (see 
Appendix  A). 
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The  steps  involved  in  database  construction  included  scheduling,  hardware  assessment  and 
acquisition,  hardware  and  software  configuration,  source  frosted  acetate  separate  reproduction, 
source  map  preparation,  digitizing/scanning,  basic  data  processing,  attribute  assignment,  edge 
matching,  tiling,  conversion  to  VPF,  CD-ROM  premastering  and  mastering,  and  packaging. 
The  standard  procedures  for  production  were  established  during  the  prototyping  phase  and 
were  documented  in  SOPs;  the  SOPs  were  updated  and  improved  continuously  during  database 
production.  Application  routines  written  in  the  ARC/INFO  Macro  Language  (AML)  were 
extensively  used  in  production  to  help  reduce  the  processing  time  and  standardize  the 
processing  procedures.  The  use  of  AMLs  and  the  development  of  additional  AMLs  during  the 
production  period  resulted  in  a  three-fold  increase  in  production  efficiency  during  the  twenty 
months  of  production. 

1.4.2  Quality  Assurance 

A  comprehensive  quality  assurance  program  was  strictly  adhered  to  during  each  process  in 
DCW  production  to  ensure  the  highest  quality  in  the  product.  The  quality  assurance  activities 
covered  four  areas:  management  activities  in  support  of  effective  overall  quality  assurance  for 
the  project,  software  development,  database  development,  and  CD-ROM  premastering  and 
mastering.  The  first  area  was  a  pivotal  component  of  the  DCW  project  infrastructure;  it 
controlled  the  inputs  and  outputs  of  the  product  development  process  and  ensured  the  quality  of 
the  final  integrated  project  deliverables.  The  other  three  areas  were  concerned  with  placing 
controls  on  specific  product  development  activities.  The  primary  focus  of  the  quality  assurance 
program  overall  was  on  the  activities  connected  with  database  development,  since  this  portion 
of  the  project  was  the  most  complex  and  labor  intensive. 

1.4.3  Operation  Desert  Shield/Desert  Storm 

While  the  DCW  was  under  development,  DMA  requested  that  ESRI  provide  GIS  database 
development  support  for  Operation  Desert  Shield/Desert  Storm.  A  great  many  technical 
resources  and  a  great  deal  of  effort  were  required  to  complete  the  digital  data  automation  of  the 
requested  geographic  areas  within  the  Kuwait  theater  of  operations  within  the  given  time  frame. 
The  urgent  requirements  of  Desert  Shield/Desert  Storm  necessitated  special  handling  and 
tasking  procedures  and  associated  complex  shifts  in  the  DCW  development  staff.  These  special 
procedures  were  implemented  in  a  timely  and  cost-effective  manner,  and  urgent  military  and 
intelligence  requirements  were  successfully  met 


1.5  Phase  III — VSM  and  DNC  Production 

Prototyping  for  two  additional  DMA  products,  the  VSM  and  the  DNC  products,  is  under  way. 
This  work  is  designed  to  meet  the  growing  demand  for  military  GIS  analysis  using  VPF  data. 
Each  of  these  products  represents  a  new  chapter  in  the  extension  of  VPF,  which  will  be  the 
standard  format  for  all  future  DMA  digital  vector  databases. 

1.5.1  The  VSM  Project 

VSM  provides  generic  topographic  data  for  a  variety  of  U.S.  Army  and  GIS  intelligence 
applications  in  two  scales  referred  to  as  medium  and  high  resolution.  The  first  VSM  prototype 
will  consist  of  two  VPF  databases  automated  from  a  1:50,000  topographic  line  map  of  Killeen, 
Texas,  and  a  Joint  Operations  Graphic  (JC  j)  of  the  Waco-Killeen  area  at  the  scale  of 
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1 :250,000,  After  the  database  is  automated  in  ARC/INFO,  it  will  be  translated  from 
ARC/INFO  to  VPF.  Additional  prototypes  are  planned.  As  with  the  DCW  product,  VSM  data 
will  be  delivered  to  DMA  on  CD-ROM.  VSM  will  use  the  Feature  Attribute  Coding  Catalog 
(FACC)  coding  scheme. 

1.5.2  The  DNC  Project 

In  a  second  application  of  the  VPF  standard,  a  navigational  database  prototype  also  coded  in 
FACC  and  formatted  in  VPF  will  be  produced.  The  DNC  project  is  a  pilot  program  that  will 
provide  the  U.S.  Navy  and  U.S.  Coast  Guard  with  a  digital  geographic  database  prototype  on 
CD-ROM  that  is  capable  of  supporting  ocean  surface  navigation.  The  DNC  prototype 
database,  which  will  range  in  scale  from  1:20,000  to  1:500,000,  is  being  populated  with  the 
feature  content  of  eleven  National  Ocean  Service  (NOS)  nautical  charts  from  the  Norfolk, 
Virginia  and  New  York  City  harbors.  The  prototype  database  will  contain  approximately 
fourteen  data  layers,  including  port  facilities,  aids  to  navigation,  limits,  obstructions,  and 
hydrography. 

In  the  future,  ship  navigation  requirements  may  be  met  through  VPF  databases  published  on 
CD-ROM  instead  of  through  traditional  paper  charts.  If  so,  significant  onboard  space  savings 
will  be  realized.  More  important,  since  spatial  navigation  systems  built  from  VPF  digital  data 
will  be  able  to  undergo  more  frequent  updates  than  paper  charts,  it  will  be  possible  to  provide 
better  descriptions  of  naval  hazards  to  mariners,  improving  the  safety  of  marine  navigation. 
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2.1  Chapter  Overview 

This  chapter  describes  the  objectives  and  characteristics  of  each  prototype,  the  special  studies 
conducted  to  determine  the  best  solution  for  specific  design  problems,  the  development  of 
vector  product  format,  and  the  development  of  VPFVIEW. 

Acronyms  are  defined  in  Appendix  E. 


2.2  Prototype  Development 

2.2.1  Prototype  1 

2.2. 1.1  Objectives 

The  objectives  of  Prototype  1  were  to  create  a  conceptual  design  for  and  to  provide  a 
preliminary  demonstration  of  the  content  of  the  DCW  database  and  the  capability  of  the 
application  software.  Since  one  objective  was  to  demonstrate  the  conceptual  design,  the 
prototype  consisted  of  very  preliminary  user-oriented  menus  and  a  minimum  amount  of  data. 
After  being  developed.  Prototype  1  was  sent  to  the  DCW  participants  for  evaluation  and 
comments. 

Prototype  1  was  completed  in  December  1989  within  eighty-three  days  after  award  of  contract 
In  November  1989,  the  Project  Requirements  Review  was  held  to  set  objectives  for  the  project 
and  the  prototypes.  Prototype  1  was  developed  in  such  a  limited  period  of  time  that  it  was 
unable  to  benefit  from  the  results  of  the  subsequent  special  studies  and  standards  development 

2.2. 1.2  Design  and  Implementation 

The  two  main  issues  addressed  with  the  development  of  Prototype  1  were  database  content  and 
the  conceptual  design  of  the  application  software. 

Database  Content  and  Design 

The  database  design  for  Prototype  1  was  topologically  structured  and  reflected  the  DCW 
product  requirement  for  layered  thematic  data  sets.  Database  design  began  with  an  analysis  of 
the  two  source  maps,  ONC  G-18  and  hydrographic  chart  BA-2693  from  Harwich,  U.K.  The 
data  layers  in  the  design  were  grouped  into  six  general  themes:  cultural,  road  network, 
hydrographic  (i.e.,  drainage  network),  elevation,  and  marginalia  (the  last  of  these  was  not 
topologically  structured).  The  database  included  all  four  ARC/INFO  feature  types  (points, 
lines,  polygons,  and  networks). 
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The  database  was  topologically  structured;  that  is,  the  spatial  information  was  treated  such  that 
all  areal  space  was  accounted  for  in  a  mathematically  rigorous  fashion.  A  naming  convention 
w  as  used  for  the  data  layers  that  indicated  both  the  general  theme  for  the  layer  and  the  feature 
type  contained  in  the  layer.  A  coding  structure  was  also  developed  for  the  types  of  features  in 
each  layer.  A  data  dictionary  reflecting  all  design  decisions  was  developed  to  guide 
Prototype  1  database  construction  and  attribute  assignment 

Database  Automation 

The  Prototype  1  database  was  manually  digitized.  ESRI's  ARC/INFO  software  was  used  to 
process  the  digitized  features  and  assign  the  associated  attributes.  The  database  was  developed 
stricdy  in  accordance  with  the  specifications  of  the  data  dictionary.  For  this  prototype,  the  data 
automated  represented  a  small  portion  of  both  source  maps. 

Application  Software  Functions  and  Capabilities 

The  application  software  provided  to  reviewers  to  evaluate  Prototype  1  was  based  on  the 
PC  ARC/INFO  software.  The  application  was  written  with  the  Simple  Macro  Language 
(SML)  programming  language.  The  application  provided  the  user  with  a  menu  structure  for 
performing  queries  and  displays.  Users  could  access  the  operating  system,  select  features, 
prepare  reports,  and  archive  data. 

The  VPFVIEW  software  later  developed  through  subsequent  prototypes  for  the  DCW  is  not 
ARC/INFO  based  and  was  written  in  C.  PC  ARC/INFO  was  used  for  Prototype  1,  only 
because  it  provided  ready-made  display  and  query  capabilities  and  could  be  used  to  rapidly 
mock  up  the  conceptual  design  and  the  look  and  feel  of  the  software  ESRI  envisioned  for  the 
final  product 

The  Prototype  1  software  capabilities  were  as  follows;  the  user  could  select  only  the  data 
automated  into  the  prototype  database,  and  no  methods  for  delimiting  specific  points  or  areas 
within  that  database  were  implemented.  The  only  functional  option  on  the  Graphic  Report 
menu  was  the  one  that  enabled  the  user  to  draw  to  screen.  For  the  Text  Report  function,  the 
functions  implemented  were  those  that  enabled  the  user  to  save  to  disk,  display  reports  to  the 
screen,  and  send  a  report  to  the  printer.  The  Archive  functions  were  implemented  that  allowed 
the  user  to  save  and  restore  data  requests  generated  from  earlier  selections  (the  Save  and 
Restore  Feature  Selection  List  options). 

Thus,  the  software  implemented  for  Prototype  1  demonstrated  the  design  concept  and  the 
potential  functions  and  capabilities  the  later  software  would  have,  although  many  of  the  menu 
options  available  in  the  final  DCW  product  were  not  yet  implemented. 

Deliverables  and  submittals  for  Prototypes  1  to  4  as  well  as  for  all  other  DCW  activities  are 
listed  in  Appendix  F. 

2.2.2  Prototype  2 

2.2.2. 1  Objectives 

The  objective  of  Prototype  2  was  to  implement  the  concepts  presented  in  Prototype  1  and  to 
incoiporate  the  feedback  generated  by  the  evaluation  of  Prototype  1.  The  application  software 
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was  coded  in  C,  and  the  study  area  was  expanded  to  include  a  larger  geographic  area.  This 
prototype  served  to  further  demonstrate  the  conceptual  design  of  the  DCW  product  It  was 
delivered  in  April  1990;  a  January  conference,  the  Design  Concept  Review,  provided  DCW 
participants  with  an  opportunity  to  discuss  Prototype  1  and  to  understand  ESRJ’s  plans  for 
Prototype  2  development 

2.2.2.2  Design  and  Implementation 

As  was  true  for  Prototype  1,  the  principal  issues  addressed  within  Prototype  2  were  database 
content  and  the  conceptual  design  of  the  applications  software. 

Database  Content  and  Design 

To  demonstrate  the  functions  and  capabilities  of  Prototype  2,  new  data  sets  were  automated. 
For  most  of  the  prototype  areas,  partial  sheets  were  automated.  Table  1  lists  all  sample  areas 
and  source  scales  for  each.  These  varied  sources  were  automated  to  ensure  that  the  DCW 
design  was  flexible  enough  to  accept  data  from  diverse  sources  that  contained  different  themes 
and  were  created  at  different  scales. 

Table  1.  Prototype  2  Sample  Areas 


Source  Map  or  Chart 

Location 

Source  Sc?le 

ONC  G-18 

Califomi  a/Nevada 

1:1,000,000 

BA  2693 

Harwich,  England 

1:25,000 

NOS  12222 

Hampton  Roads,  Virginia 

1:40,000 

NOS  12245 

Hampton  Roads,  Virginia 

1:20,000 

Topographic  map 

Killeen.  Texas 

1:50,000 

Some  aspects  of  the  Prototype  2  database  design  were  reworked,  and  the  data  inclusion  criteria 
were  modified,  as  the  result  of  Prototype  1  feedback.  As  for  Prototype  1,  all  data  from  all 
sources  were  grouped  in  layers,  and  layers  were  grouped  in  themes. 

The  new  data  layers  added  to  the  Prototype  2  database  included  Political  Boundaries/ 
Administrative,  Miscellaneous  Culture,  Utilities,  Air  Transportation,  Navigation  Demarcation, 
Bathymetry,  and  Isogonic  Lines.  In  addition,  for  all  data  sets  associated  with  selected 
geographic  layers,  an  annotation  layer  was  automated. 

Data  Structure  and  Symbology 

Like  the  data  for  Prototype  1,  the  data  for  Prototype  2  were  encoded  in  the  ARC/INFO  data 
structure.  The  study  that  led  to  the  development  of  VPF  (the  data  structure  used  for  the  final 
product)  was  initiated  after  Prototype  2  was  released  and  applied  to  the  DCW  data  sets 
beginning  with  Prototype  3.  VPF  will  be  discussed  in  greater  detail  later. 

Similarly,  the  symbology  utilized  for  Prototype  2  did  not  take  into  account  results  from  the 
symbology  study  (see  Section  2.3.6),  since  the  symbology  study  was  undertaken  while 
Prototype  2  was  being  developed. 
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Database  Automation 

Starting  with  Prototype  2,  the  feasibility  of  using  scanning  techniques  to  capture  data  was 
explored.  Benchmarks  were  designed  and  implemented  on  a  variety  of  different  scanning 
hardware  and  vectorization  software  configurations  to  test  the  cartographic  accuracy  of  the 
results.  The  principal  determining  factor  for  scanner/vectorization  software  selection  was  the 
quality  of  linework  exiting  the  vectorization  processor.  Analysis  during  this  time  period 
showed  that  vectorization  algorithms  which  first  calculated  a  "casing"  around  linework  and 
then  calculated  a  centerline  from  the  casing  were  superior  to  so-called  "pealing"  algorithms. 
Additional  analysis  regarding  scanner  resolution  indicated  that  to  achieve  the  DCW  line 
accuracy  specification,  scanners  with  400  Dots  Per  Inch  (DPI)  to  500  DPI  provided  sufficient 
scanning  resolution.  No  DCW  data  were  scanned  at  a  higher  resolution  than  500  DPI. 

For  Prototype  2,  the  elevation  contours  in  ONC  G-18  were  selected  and  scanned;  all  other 
types  of  data  were  digitized  manually.  The  scanned  data  were  converted  from  raster  data 
format  to  vector  data  format  by  using  vectorization  software.  ARC/INFO  utilities  were  then 
applied  to  transfer  the  vectorized  data  from  DXF  format  to  ARC/INFO  vector  data  format 
Data  processing  and  editing  were  then  performed  in  the  ARC/INFO  environment  For  the 
manually  digitized  data,  ARC/INFO  software  was  used  to  support  the  digitizing  process  and  to 
assign  feature  attributes. 

Application  Software  Concept 

The  user  interface  was  considered  key  to  the  success  of  the  application  software.  Therefore,  as 
for  Prototype  1,  the  user  interface  for  Prototype  2  was  intended  to  closely  resemble  the 
interface  to  be  used  for  the  final  DCW  product.  The  focvs  of  sof*ware  development  continued 
to  be  a  "core"  subset  of  the  final  software’s  capabilities,  such  as  ii  query/selection  and  graphic 
display  capabilities. 

Application  Software  Design  and  Development 

Many  concepts  designed  but  not  yet  implemented  in  Prototype  1  were  implemented  in 
Prototype  2.  In  addition,  some  new  capabilities  were  designed  and  included  in  Prototype  2  in 
response  to  participant  evaluations  of  Prototype  I.  These  included  a  "mouse"  interface,  a  zoom 
capability,  and  more  straightforward  ways  to  move  between  menus. 

Beginning  with  Prototype  2,  all  software  was  designed  and  coded  in  C.  This  was  a  major 
difference  between  Prototypes  1  and  2;  since  Prototype  1  was  based  on  PC  ARC/INFO  and  the 
application  software  was  coded  by  using  SML,  none  of  the  Prototype  1  code  was  utilized  in 
Prototype  2. 

An  on-line  data  dictionary  was  designed  and  implemented  for  Prototype  2.  It  was  intended  to 
provide  the  user  with  on-line  information  about  the  DCW  project  and  the  database  structure, 
layer  and  feature  content,  and  code  correspondence  to  the  DIGEST  FACC  codes  or  other 
coding  systems.  In  later  prototypes,  the  on-line  data  dictionary  was  expanded  to  allow  the  user 
to  review  the  contents  of  the  DCW  product  or  to  query  specific  attribute  code  values  for 
features  of  interest.  For  example,  for  the  final  product,  the  data  dictionary  may  be  queried  for 
attribute  code  values.  For  Prototype  2,  a  query  of  the  data  dictionary  resulted  only  in  a  listing 
of  an  A SCn  file  containing  the  physical  design  of  a  specific  layer. 
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Also  in  Prototype  2,  a  code  correspondence  option  was  implemented  that  displayed  a  cross- 
reference  between  the  ONC  symbol  codes  and  the  DIGEST  FACC  codes  and  DCW  codes. 

A  gazetteer  function  (place  name  index)  was  implemented  in  Prototype  2  that  allowed  the  user 
to  select  areas  of  interest  by  name.  The  user  entered  the  desired  feature  name  in  a  fill-in  box, 
and  the  software  responded  with  a  list  of  the  place  names  that  began  with  the  letters  specified. 

In  all,  the  core  commands  that  were  not  functional  in  Prototype  1  were  successfully 
implemented  in  Prototype  2.  However,  peripheral  commands  that  appeared  in  the  final  product 
were  not  yet  implemented  in  this  prototype,  including  Text  Report,  Select  by  Box,  Select  by 
Latitude/Longitude,  and  Select  by  Pointing. 

2.2.2.3  Summary 

Prototype  2  exceeded  its  original  design  objectives,  and  significant  progress  was  made  toward 
a  final  database  and  software  design.  For  the  database,  the  data  inclusion  criteria  were 
modified,  and  the  database  was  expanded  to  include  themes  and  layers  that  were  not  present  in 
Prototype  1.  For  the  application  software,  the  functions  and  capabilities  of  Prototype  2 
surpassed  those  of  Prototype  1  in  terms  of  "look  and  feel,"  query/selection  capabilities,  and 
graphic  display  capabilities. 

The  aspects  of  Prototype  2  that  were  not  representative  of  the  final  DCW  product  included  data 
structure  and  symbology.  The  data  for  Prototype  2  were  still  in  ARC/INFO  format,  whereas 
the  data  for  the  final  DCW  product  would  be  in  VPF.  The  symbology  used  for  Prototype  2 
was  also  part  of  an  ARC/INFO  utility.  Symbology  designed  specifically  for  the  DCW  product 
was  implemented  in  the  next  prototype.  It  should  also  be  noted  that  Prototype  2  was 
developed  without  the  full  benefit  of  the  special  studies  and  standards  that  were  being 
developed  concurrently. 

2.2.3  Prototype  3 

2.2.3. 1  Objectives 

The  objectives  for  Prototype  3  were  to  finalize  the  DCW  database  content  and  to  fully 
implement  all  software  functions.  The  extent  of  data  to  be  automated  was  further  expanded, 
and  production  procedures  for  database  development  were  established.  The  Prototype  3 
database  was  the  first  to  be  delivered  on  CD-ROM,  and  it  was  the  first  database  to  be  prepared 
in  vector  product  format.  However,  the  VPF  standard  continued  to  evolve  beyond  this  point. 

Prototype  3  was  delivered  in  August  1990.  Review  comments  on  Prototype  2  and  ESRI's 
plans  for  Prototype  3  development  were  discussed  at  the  Preliminary  Design  Review  in  May. 

2.2.3.2  Design  and  Implementation 
Database  Content 

Large  sample  areas  were  included  in  the  Prototype  3  database.  For  most  of  the  prototype 
areas,  complete  sheets  were  automated.  Table  2  lists  all  sample  areas  and  source  scales  for 
each.  The  DMA's  Digital  Air  Facilities  Information  File  (DAFIF)  was  used  to  extract  airport 
information  for  the  aeronautical  layer.  The  database  for  Prototype  3  incorporated  data  from 
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varied  sources  and  at  different  scales  to  show  that  the  VPF  data  structure  was  flexible  enough 
to  accept  data  from  sources  other  than  the  ONCs. 

Table  2.  Prototype  3  Sample  Areas 


Source  Map  or  Chart 

Location 

■■■KKSSSiMH 

ONCQ  -1$ 

Califomia/Nevada 

■■MillMlTlTlSHI 

ONCE- 18 

Quebec,  Canada 

1:1,000,000 

ONC  N-13 

Northern  Territory,  Australia 

1:1,000,000 

JNC  120 

Antarctica 

1:2,000,000 

BA  2052 

Harwich,  England 

1:50,000 

NOS  12245 

Hampton  Roads,  Virginia 

1:20,000 

Topographic  map 

Killeen,  Texas 

1:50,000 

Nine  new  layers  were  added  to  the  DCW  design,  one  layer  was  deleted,  and  minor  design 
changes  were  made  to  other  layers. 

All  data  sets  were  automated  in  ARC/INFO  coverages.  A  prototype  data  format  converter  was 
designed  and  developed  in  C  to  convert  data  in  ARC/INFO  data  format  to  VPF. 

Database  Design  and  Vector  Product  Format 

The  Prototype  3  database  was  different  from  the  previous  prototypes  in  that  the  data  structure 
used  was  vector  product  format  Throughout  the  Prototype  3  and  4  timeframe,  VPF  continued 
to  evolve  based  on  data  handling  experiences  from  the  two  prototypes. 

Vector  product  format  can  support  spatial  query,  display,  and  modeling  directly  (without 
conversion  to  another  format).  The  VPF  data  model  is  flexible  in  that  it  provides  a  data 
structure  that  can  be  tailored  to  particular  needs  and  applications.  The  study  that  culminated  in 
the  development  of  VPF  was  initiated  after  Prototype  2  and  was  applied  to  the  Prototype  3  data 
sets.  VPF  is  discussed  further  in  Section  2.4. 

Like  the  databases  for  Prototypes  1  and  2,  the  database  for  Prototype  3  was  arranged  in  layers 
that  contained  specific  features  or  feature  groups  and  associated  attributes.  Each  thematic  layer 
was  stored  as  a  single  coverage.  The  features  in  the  thematic  layers  were  defined  by  attributes 
and  attribute- value  code  combinations. 

Production  Procedures 

During  the  Prototype  3  period,  production  procedures  continued  to  be  developed.  These 
procedures  were  documented  in  SOPs  that  were  held  in  a  document  nearly  300  pages  long. 

Symbology 

The  other  important  difference  between  Prototype  3  and  the  two  previous  prototypes  was  that 
the  symbols  used  in  Prototype  3  were  designed  specifically  for  the  DCW  product.  Prototype  3 
also  provided  the  user  with  limited  cartographic  design  and  symbology  options.  The  symbol 
sets  designed  for  Prototype  3  included  the  drawing  primitives  supplied  with  the  C  graphic 
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library  (simple  lines  and  polygons),  the  ASCII  character  set  (points),  a  minimal  set  of  complex 
line  algorithms,  and  a  preliminary  library  of  marker  symbols  (points). 

Although  the  actual  symbol  design,  color  selection,  line  styles,  area  patterns,  and  point 
symbols  continued  to  evolve,  the  Prototype  3  symbology  reflected  the  efforts  described  in  the 
initial  symbolization  study,  which  was  undertaken  to  evaluate  considerations  of  cartographic 
design,  feature  symbology,  and  the  capabilities  of  the  software  to  present  a  more  typical  map 
display. 

Application  Software  Design  and  Implementation 

As  with  the  previous  two  prototypes,  efforts  were  made  with  Prototype  3  to  develop  a  menu 
structure  that  would  match  the  final  DCW  product  as  closely  as  possible,  even  though  some  of 
the  menu  commands  were  not  implemented. 

For  Prototype  3,  the  development  of  software  functionality  included  the  development  of 
display  functionality  (and  the  associated  symbology),  spatial  and  attribute  query  functionality, 
indexing  capabilities,  and  gazetteer/functionality.  Participant  comments  on  Prototype  2  were 
carefully  evaluated  and  implemented  in  Prototype  3. 

Several  new  user-oriented  functions  were  added,  including  a  high-level  "screen  draw" 
command,  adaptive  menus,  a  map  distance-measuring  function,  a  map  scale  function, 
projection  capabilities,  and  status  windows. 

Software  graphic  display  capabilities  were  modified  in  Prototype  3  so  that  features  could  be 
selectively  added  to  a  display  after  the  main  part  of  the  display  had  already  been  drawn  on  the 
screen. 

CD-ROM  Design  and  Implementation 

Since  the  final  DCW  product  was  to  be  distributed  on  the  CD-ROM  media,  production  steps 
regarding  the  premastering  and  mastering  of  CD-ROMs  for  data  storage  were  also  conducted 
during  this  prototype.  In  addition  to  the  DCW,  database-supporting  data  such  as  indexes, 
quality  reports,  and  gazetteer  and  data  dictionary  information  were  also  stored  on  the 
CD-ROM. 

The  CD-ROM  manufacturing  task  involved  the  transferring  of  digital  source  data  from 
magnetic  media  to  the  CD-ROM.  The  task  had  two  primary  phases:  premastering  and 
mastering.  Premastering  involved  testing  data  integrity  at  a  number  of  key  steps  in  the  process. 
Mastering  involved  producing  master  "molds"  and  monitoring  the  physical  characteristics  of 
the  discs.  During  CD-ROM  premastering  for  Prototype  3,  ESRI  successfully  organized  the 
database  into  four  libraries  that  contained  all  data  in  the  geographic  sample  areas. 

2.2.4  Prototype  4 

2.2.4. 1  Objectives 

Prototype  4,  which  was  delivered  in  December  1990,  fully  implemented  the  database  revisions 
and  the  new  application  software  functions  based  on  Prototype  3  reviewer  comments. 
Prototype  3  and  plans  for  Prototype  4  were  discussed  at  the  Project  Detail  Design  Review  in 
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August.  This  prototype  served  as  a  production  "dry-run,"  and  a  thorough  set  of  SOPs  for  the 
full-scale  production  process  was  developed  as  the  prototype  was  produced.  From  this 
prototype,  the  prototype  reviewers  received  a  very  close  mockup  of  the  appearance  and 
operation  of  the  final  DCW  product 

2. 2.4.2  Design  and  Implementation 

Prototype  4  represented  revisions  in  database  content  and  accuracy;  the  implementation  of  new 
application  software  functions  and  capabilities;  the  further  development  of  VPF;  the 
development  of  a  software  users  manual;  the  development  of  final  symbology;  die 
implementation  of  a  database  tiling  structure;  the  finalization  of  production  procedures;  and  the 
establishment  of  database  quality  assurance  procedures. 

Database  Content 

Data  from  four  ONCs  of  Western  Europe  made  up  the  Prototype  4  database:  ONC  E-l, 

ONC  F-l,  ONC  G-l,  and  ONC  G-2.  Five  new  thematic  layers  were  added  to  the  DCW 
design:  Vegetation,  Landmarks,  Transportation  Structure,  Hypsography  Supplemental,  and 
Drainage  Supplemental. 

The  Vegetation  layer  contained  those  areas  that  were  labeled  "vegetation"  or  "clearing"  on  the 
ONCs.  The  vegetation  data  were  represented  as  polygons.  The  Landmarks  layer  contained 
point  and  polygon  features  that  were  captured  on  the  ONCs  because  of  their  visual  prominence. 
The  Transportation  Structure  layer  contained  a  variety  of  transportation  features  that  were 
added  to  the  DCW  design  to  supplement  the  Road  and  Railroad  layers.  The  features  in  this 
new  layer  included  bridges,  tunnels,  causeways,  ferries,  fords,  and  so  forth;  they  were 
represented  by  points  and  polygons. 

The  Hypsography  Supplemental  layer  was  introduced  to  capture  small  contour  areas  as  points 
(those  with  a  circumference  less  than  0.12  inch).  These  small  polygons  were  not  captured  in 
previous  prototypes  because  they  could  not  be  captured  as  polygons.  In  this  layer,  they  were 
captured  and  converted  to  elevation  points. 

In  the  new  Drainage  Supplemental  layer,  as  in  the  Hypsography  Supplemental  layer,  small 
polygons  in  the  Drainage  layer  (those  with  a  circumference  less  than  0.12  inch)  were  captured 
and  converted  to  points.  In  the  Drainage  Supplemental  layer,  these  small  polygons  mainly 
represent  small  lakes  and  small  islands  in  inland  lakes. 

Prototype  4  also  introduced  a  new  approach  tc  the  representation  of  elevation  data.  The  point 
and  line  coverages  within  the  Hypsography  layer  remained  largely  the  same,  but  the  polygon 
coverage  was  revised  to  contain  six  elevation  zones.  Stones  were  introduced  because  they 
reflected  distinctions  with  respect  to  a  number  of  important  natural  and  cultural  factors, 
including  vegetation  patterns,  agricultural  land  use,  population  distribution,  equipment 
performance,  and  human  health  and  comfort. 

Mod:fications  to  the  VPF  Military  Standard  within  Prototype  4 

Three  primary  goals  were  set  for  VPF  data  structure:  to  support  spatial  and  thematic  display, 
query,  and  modeling;  to  support  tiling  and  the  sheetless  assembly  of  tiles;  and  to  support  work 
with  a  wide  range  of  media,  including  CD-ROM,  tape,  and  hard  disc.  Significant  effort  was 
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applied  to  the  development  of  this  data  structure  and  the  related  military  standard  (see 
Section  2.4). 

The  implementation  of  VPF  in  Prototype  3  signaled  the  beginning  of  the  standardization  of  the 
DCW  data  storage  format  The  VPF  military  standard  was  revised  to  explain  VPF  in  terms  of  a 
five-level  hierarchy  that  included  the  product  specification,  a  data  model,  the  data  structures, 
encapsulation,  and  data  syntax.  The  revised  standard  proved  its  flexibility  through  its 
successful  application  to  Prototype  4.  The  ARC/INFO-to-DCW  converter  initially  created  to 
support  Prototype  3  was  modified  to  convert  Prototype  4  ARC/INFO  data  into  VPF. 

Applications  Software  Functions 

The  software  capabilities  provided  by  Prototype  4  were  representative  of  all  user-oriented 
functions  of  the  final  DCW  software.  Subsequent  modifications  to  the  software  focused  on 
internal  engineering,  performance  enhancement,  and  extension  of  the  software  to  read  any  VPF 
database.  (Because  of  this  extension,  the  name  of  the  software  was  changed  from  "DCW 
Applications  Software"  to  "VPFVIEW.")  Additions  and  refinements  suggested  by  participants 
after  reviewing  Prototype  3  were  carefully  considered,  and  many  were  incorporated  in  the  final 
software  design.  New  functions  and  capabilities  provided  by  Prototype  4  were  as  follows: 

■  Zoom — Users  could  zoom  in  and  out  of  the  DCW  database.  The  zoom  capability  could 
also  be  used  to  move  from  the  DCW  Browse  map,  which  was  the  first  data  set  visible 
to  the  user,  to  the  more  detailed  DCW  data  set,  and  vice  versa. 

■  Help — Users  could  access  a  Help  option.  Help  was  available  at  both  the  main  and 
pulldown  menu  levels. 

■  Generated  Graphics — Users  could  generate  two  types  of  graphics:  (1)  a  latitude/ 
longitude  grid  and  (2)  a  scale  bar. 

■  Status  Windows — Status  Windows  were  provided  to  show  the  software  operations 
(e.g.,  drawing,  initialization). 

■  Select  by  Pointing,  Latitude/Longitude,  or  Place  Name — Users  could  select  an  area  of 
interest  by  pointing  the  cursor  at  any  geographic  location  on  the  Browse  map.  Users 
could  also  specify  an  area  of  interest  by  entering  latitude/longitude  or  place  name. 

■  Text  Report — Users  could  produce  three  types  of  text  reports.  The  Feature  Location 
List  and  the  Area  Content  Summary  contained  attribute  information  for  selected  features 
within  a  specific  study  area.  The  Feature  Location  List  provided  a  report  of  the  location 
of  these  attributes,  while  the  Area  Content  Summary  provided  a  report  of  feature  type 
and  count  The  international  Feature  Attribute  Coding  Catalogue  (FACC) 
correspondence  report  contained  a  table  comparing  the  DCW  and  FACC  coding 
schemes.  (FACC  is  the  coding  structure  for  the  DIGEST  standard.) 

■  Spatial  Query — Users  could  identify  the  attribute  characteristics  of  displayed  features 
by  pointing  the  cursor  at  a  geographic  location  on  the  screen. 

■  PostScript  interface — Users  could  generate  a  PostScript  plot  file  of  the  selected  features 
by  using  the  Hardcopy  option  on  the  Graphics  menu. 
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Browse  Map 

The  most  obvious  change  to  software  functionality  was  the  design  and  implementation  of  a 
Browse  map  for  Prototype  4.  It  replaced  the  index  map  provided  with  the  previous  prototype. 
The  Browse  map  was  a  basemap  that  was  designed  to  accomplish  four  objectives:  (1)  to  serve 
as  a  start-up  screen  for  the  DCW;  (2)  to  provide  an  index  map  for  the  user;  (3)  to  allow  the 
display  of  metadata;  and  (4)  to  provide  a  bounding  geographic  area  context  to  support  zoom- 
outs.  In  operating  the  Browse  map,  the  user  could: 

■  Select  a  specific  area  of  the  DCW  to  examine  in  greater  detail 

■  Manipulate  the  zoom  function  to  move  from  the  Browse  map  data  set  into  the  DCW 
data  set  and  back  out  again. 

■  Retrieve  metadata  (e.g.,  compilation  dates  data  volumes,  and  data  availability)  from  the 
DCW  data  set 

Development  of  the  DCW  Applications  Software  Users  Manual 

A  software  users  manual  was  developed  for  use  with  Prototype  4.  The  manual  described  the 
DCW  applications  software  and  explained  its  use.  This  document  also  described  system 
requirements  and  provided  a  high-level  design  description.  The  manual  enabled  the  user  to 
operate  the  DCW  display  software  and  to  understand  many  aspects  of  system  design.  The 
users  manual  ultimately  served  as  a  mock-up  for  the  "VPFVIEW  Users  Manual  for  the  DCW," 
which  was  distributed  with  the  DCW  in  1992. 

Symbology  Development 

As  with  Prototype  3,  a  full  default  symbol  set  was  provided  for  this  prototype,  which  could  be 
altered,  added  to,  or  completely  replaced  by  the  user.  However,  several  changes  were  made  to 
the  design  and  implementation  of  the  Prototype  4  symbology. 

Text.  The  main  objective  of  changing  the  symbology  used  for  Prototype  4  was  to  reduce 
clutter  (crowding),  especially  for  text  Therefore,  for  Prototype  4  the  text  was  scaled  directly 
in  proportion  to  its  relative  size  in  the  source  ONC.  The  size  of  the  text  was  also  related  to  the 
scale  (zoom  factor)  selected  by  the  user.  Text,  if  selected,  was  displayed  regardless  of  display 
scale  (the  display  of  text  was  not  disabled  at  small  scale).  To  avoid  clutter  at  small  scale,  text 
appeared  as  a  row  of  pixels.  As  the  user  operated  the  zoom  function  to  increase  the  display 
scale,  the  size  of  the  text  increased  proportionally.  Text  became  increasingly  legible  with  each 
successive  zoom. 

Another  design  change  for  Prototype  4  was  that  the  user  was  able  to  select  the  color  used  for 
the  text  (by  overriding  the  default  text  color).  Providing  this  functionality  was  essential  to  keep 
text  visible  yet  give  the  user  a  free  choice  of  color  for  areas. 

Points.  Several  additions  were  made  to  the  feature  symbology  set  in  Prototype  4;  there  was  a 
digital  version  of  almost  every  point  symbol  in  the  ONC  source,  even  though  some  of  them 
were  redesigned  later  in  the  final  DCW  product 
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Lines.  Primarily  because  of  the  limits  of  screen  resolution,  line  symbology  remained  less  than 
ideal  for  Prototype  4.  However,  the  quality  of  the  "dot"  and  "dash"  line  patterns  generated  by 
the  software  was  substantially  better  than  in  Prototype  3.  Line  symbology  could  be  optimized 
through  the  selection  of  line  color  and  thickness. 

Areas.  One  of  the  most  important  improvements  to  Prototype  4  feature  symbology  was  a  new 
approach  to  area  fill.  Area  fill  for  Prototype  4  was  provided  exclusively  by  color,  and  the  color 
could  be  controlled  by  the  user  through  the  "pixel  mixing"  technique  presented  at  the  Project 
Detail  Design  Review.  The  user  could  control  color  through  the  menu  by  selecting  a  color  for 
each  of  the  four  pixels  that  make  up  a  given  color.  The  objective  of  using  color  fill  was  to 
replace  the  cross-hatching  and  other  pattern  area  fills  used  in  Prototype  3,  which  produced 
clutter  and  detracted  from  the  readability  of  the  display. 

Database  Tiling 

The  tiling  or  database  partitioning  scheme  for  the  DCW  product  was  designed  and  implemented 
in  Prototype  4.  The  tiling  scheme  is  largely  invisible  to  the  user,  but  it  is  of  tremendous 
interest  to  the  database  designer  because  of  its  role  in  database  management  and  its  impact  upon 
system  performance.  The  tiling  scheme  (tile  size  and  the  number  of  tiles)  implemented  was 
evaluated  for  both  design  effectiveness  and  effectiveness  of  performance. 

Two  tiling  schemes  were  proposed  and  presented  for  evaluation:  a  5-by-5-degree  data  partition 
and  a  3-by-3-degree  data  partition.  For  Prototype  4,  features  could  be  drawn  to  screen  by 
using  either  partition. 

Within  the  tiling  design  study  that  preceded  Prototype  4,  two  fundamentally  different  tiling 
schemes  were  considered:  adaptive  and  fixed.  Because  of  its  ability  to  manage  large  variations 
in  data  density,  an  adaptive  rather  than  a  fixed  tiling  scheme  was  initially  believed  to  be  the 
best  However,  as  the  DCW  evolved  through  the  prototyping  process,  it  became  clear  that  the 
value  of  managing  variations  in  data  density  would  have  to  be  weighed  against  the 
disadvantages  of  any  adaptive  tiling  scheme  for  other  aspects  of  the  DCW  product,  particularly 
the  DCW  production  process  and  the  ability  to  overlay  the  DCW  database  with  future  VPF 
products. 

By  the  time  Prototype  3  was  released,  a  fixed  tiling  scheme  was  recommended  because  fixed 
tifing  provided  an  effective  data  range,  allowed  database  production  to  proceed  independent  of 
conversion  to  DCW  format,  and  provided  a  predictable  framework  for  other  efforts,  including 
geographic  organization. 

The  size  of  the  tiles  was  decided  after  the  performance  of  Prototype  4  was  thoroughly 
examined.  At  that  time,  ESRI  considered  the  use  of  larger  tiles  (including  7.5  by  7.5  degrees 
and  10  by  10  degrees)  to  reduce  the  number  of  tiles  and  improve  performance.  However, 
because  of  the  limitations  imposed  by  software  operating  on  a  small  machine  (286  or  386),  a  5- 
by-5-degree  tiling  scheme  was  eventually  chosen  for  the  final  DCW. 

Database  Automation 

The  most  obvious  improvement  in  database  automation  for  Prototype  4  was  the  large-scale  use 
of  scanning;  scanning  was  faster  than  manual  techniques  for  capturing  linear  features  and 
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features  bounded  by  polygons.  In  some  situations,  scanning  was  also  used  to  capture  point 
features.  Database  automation  for  DCW  production  is  described  in  more  detail  in  Chapter  3. 

Edge  Matching 

Prototype  4  was  the  first  prototype  to  contain  adjacent  ONC  sheets  and  therefore  represented 
the  first  opportunity  to  employ  and  examine  edge  matching  procedures  for  the  DCW.  Edge 
matching  issues  are  those  connected  with  locational  accuracy,  sheet  overlap,  and  attribute 
coding. 

Locational  accuracy  is  an  issue  because  some  linear  features  did  not  match  across  map  sheet 
boundaries.  In  these  cases,  the  linear  features  from  the  less  accurate  ONC  sheets  were  matched 
to  those  in  the  more  accurate  sheets. 

Overlap  existed  between  adjacent  ONC  sheets.  The  features  within  the  overlap  area  did  not 
always  match  because  different  sheets  had  different  compilation  dates.  The  solution  was  to  use 
only  the  overlap  area  from  the  more  recent  of  the  two  sheets  as  a  data  source. 

Because  of  different  compilation  dates,  attribute  coding  often  changed  across  module 
boundaries.  When  this  occurred  with  linear  features,  a  pseudonode  was  placed  on  the  module 
boundary  and  the  linear  features  were  coded  separately.  When  attribution  of  polygonal  features 
changed  at  map  sheet  boundaries,  the  polygon  was  split  along  the  module  border,  and  the 
faces,  as  well  as  their  composite  edges,  were  coded  separately. 

Development  of  Standard  Operating  Procedures 

One  of  the  main  objectives  of  developing  the  DCW  was  to  establish  standard  procedures  for 
database  development.  Therefore,  during  Prototype  4,  as  production  was  planned,  detailed 
SOPs  were  written.  The  Prototype  4  SOPs  developed  in  this  manner  were  not  final,  since 
some  of  the  production  procedures  were  modified  during  the  production  process;  however,  the 
Prototype  4  SOPs  served  as  the  foundation  for  the  final  production  SOPs. 

DCW  Product  Specification  Development 

The  draft  version  of  the  DCW  product  specification  was  developed  for  this  prototype.  The 
product  specification  was  written  to  provide  a  fully  detailed  description  of  the  DCW. 
Accordingly,  the  specification  includes  both  explanations  of  the  format  of  the  various  types  of 
VPF  tables  used  for  the  database  and  detailed  lists  of  the  content  of  each  database  layer.  The 
final,  approved  version  of  the  specification  (which  is  available  at  the  address  listed  in 
Appendix  B)  also  includes  DCW-to-F ACC/FACS  code  conversion  tables. 

The  final,  approved  version  of  the  specification  represents  the  seventh  iteration  of  the 
specification.  Each  version  reflected  expansions  in  the  database  and  also  the  gradual 
development  of  VPF.  The  first  version  was  released  with  Prototype  2;  at  that  time  the  database 
was  in  the  earliest  stages  of  development,  and  the  specification  merely  represented  an  outline  of 
intended  product  content.  The  second  (interim)  version  of  the  specification  was  released 
concurrent  with  Prototype  3,  and  the  fourth  (draft)  version  of  the  specification  was  released 
concurrent  with  Prototype  4.  Each  of  these  and  the  later  versions  of  the  specification  reflected 
the  gradually  expanding  database  and  more  results  of  the  studies  that  were  being  completed  at 
that  time. 
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2.2. 4.3  Summary 

Prototype  4  represented  fully  functional  DCW  application  software  and  a  supporting  database. 
As  the  final  prototype,  the  standards  and  procedures  developed  for  this  prototype  established 
the  guidelines  for  the  subsequent  production  of  the  full-scale  DC!W.  As  a  result,  some 
important  issues  concerning  database  content  and  application  software  were  addressed  in 
Prototype  4,  including  database  content  and  data  accuracy  for  small  polygon  features.  More 
advanced  software  functionalities  were  implemented,  including  zoom,  help,  generated 
graphics,  and  a  Browse  map.  The  results  of  some  special  studies  were  also  implemented  in 
this  prototype,  including  studies  made  to  evaluate  symbology  and  tiling  structure.  Quality 
assurance  activities  established  for  production  procedures  were  effectively  implemented  in  this 
prototype.  Most  important,  the  VPF  concept  was  redesigned  and  implemented  within  this 
prototype. 

Prototype  4  was  the  last  prototype  and  signaled  the  beginning  of  full-scale  production.  The 
implementation  of  application  software  was  finalized  and  the  future  focus  of  software  was  on 
software  engineering  and  the  associated  preparation  of  a  software  product  (versus  a  pro  tor -pe) 
At  the  end  of  this  prototype  phase,  resources,  procedures,  quality  control,  and  facilities  were 
all  ready  for  full-scale  DCW  production. 


2.3  Special  Studies 

2.3.1  Aeronautical  information  Study 

The  aeronautical  information  study  was  one  of  a  series  of  special  studies  conducted  during  the 
DCW  project  The  main  objectives  of  the  aeronautical  information  study  for  the  DCW  were  to 
determine  what  types  of  aeronautical  information  should  be  included  in  the  DCW  and  to 
recommend  a  methodology  for  the  capture  of  aeronautical  information.  (The  aeronautical 
information  on  the  ONCs  and  JNCs  included  navigation  aids,  airfields,  obstructions,  and  flight 
control  zone  information.)  A  secondary  objective  of  this  study  was  to  determine  whether 
aeronautical  information  should  be  held  in  a  separate  limited  distribution  file  that  Department  of 
Defense  users  could  overlay  on  the  DCW  product 

The  results  of  the  aeronautical  information  study  were  presented  in  initial  and  final  reports. 

The  initial  report  described  the  methodology  used  to  select,  portray,  and  compile  the 
aeronautical  information  in  the  ONC  series.  The  types  of  information  in  the  ONCs  were 
categorized  and  described.  The  results  of  an  assessment  of  user  needs  for  aeronautical 
information  in  the  DCW  were  described,  guidelines  for  data  evaluation  were  established, 
recommendations  concerning  types  of  aeronautical  information  to  be  included  in  the  DCW  were 
made,  and  sources  for  the  aeronautical  information  to  be  included  in  the  DCW  were 
recommended.  The  initial  study  was  finished  in  February  1990;  it  was  distributed  to  DMA  and 
DCW  participants  for  review.  Comments  from  the  evaluation  were  considered  for 
incorporation  in  the  final  study. 
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The  final  study  made  further  recommendations  concerning  the  inclusion  of  aeronautical 
information  in  the  DCW.  Its  recommendations  were  implemented  in  Prototypes  3  and  4.  The 
final  study  also  made  recommendations  concerning  the  query  and  display  of  aeronautical 
information. 

As  a  result  of  these  studies  and  an  assessment  of  user  needs,  it  became  clear  that  the  DCW 
should  not  be  used  for  flight  planning  or  actual  aircraft  operation.  Therefore,  the  information 
on  the  ONCs  concerning  air  traffic  control  zones  and  vertical  obstructions  was  not  included  in 
the  final  database.  However,  the  location  of  airports  was  retained.  The  data  source  for  airports 
in  the  former  Eastern  Bloc  nations  was  the  ONCs.  The  data  source  for  airports  in  the  free 
world  was  the  DMA  Digital  Aeronautical  Flight  Information  File.  A  small  subset  of  the  DAFIF 
attributes  was  also  entered  in  the  database. 

2.3.2  Elevation  Data  Study 

2.3.2. 1  Objectives 

The  elevation  data  study  was  undertaken  with  the  following  objectives: 

■  To  determine  the  categories  of  ONC  elevation  data  needed  in  the  DCW. 

■  To  determine  what  form  the  elevation  data  should  take,  including  the  display  of  the 
digital  elevation  data  to  the  user. 

■  To  determine  whether  other  sources  of  elevation  data,  such  as  Digital  Terrain  Elevation 
Data  (D TED),  could  be  used,  and  if  so,  which. 

2.3.2.2  Elevation  Data  Present  on  the  ONCs 

The  elevation  data  study  entailed  understanding  the  methods  used  to  acquire  and  depict 
elevation  data  in  the  ONC  series.  A  visit  to  DMAAC  in  St.  Louis  was  thus  made  in  order  to 
discuss  ONC  chart  creation  with  DMAAC  production  staff. 

The  elevation  data  for  the  ONCs  were  acquired  from  large-scale  maps,  which  were 
photographically  reduced  and  placed  edge  to  edge,  creating  a  mosaic  that  fit  a  computer¬ 
generated  graticule;  the  graticule  was  projected  and  scaled  to  match  the  ONC  being  developed. 
This  compilation  process  resulted  in  the  grid  controlling  the  orientation  of  the  manual  pasteup 
mosaics  of  selected  elevation  source  data,  and  lessened  the  control  problems  typically 
associated  with  manual  pasteup  procedures.  Adjustments  were  made  if  they  were  necessary  to 
create  a  good  "match"  between  the  source  documents  and  the  ONC  maps.  These  compilation 
procedures  maintained  the  positional  relationships  between  the  elevation  data  (contours  and 
spot  elevations)  and  other  ONC  data. 

The  most  common  contour  intervals  on  the  ONC  charts  were  1,000  feet  (the  basic  contour 
interval);  2,000  feet  in  mountainous  areas;  and  500  feet  in  flat  areas,  especially  coastal  areas. 
Intermediate  250-  or  200-foot  contour  intervals  were  also  used.  The  elevation  data  were 
enhanced  by  tinting  and  shading  of  the  terrain  relief.  Point  elevation  data  were  also  present  on 
the  ONCs. 
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A  significant  number  of  charts  were  devoid  of  elevation  data.  Contour  coverage  was  less  than 
100  percent  on  173  charts,  and  some  of  these  did  not  have  elevation  data  at  all. 

2.3.2.3  Assessment  of  User  Needs  for  Elevation  Data 

As  part  of  the  elevation  data  study,  user  needs  were  assessed.  Questionnaires  were  distributed 
to  DCW  participants,  and  the  best  way  to  process  and  store  elevation  data  was  then  discussed 
at  the  Design  Concept  Review  in  January  1990.  Most  of  the  respondents  to  the  questionnaire 
felt  that  elevation  data  were  most  useful  if  presented  as  an  arrayed  (Le.,  grid,  or  raster)  data  set 
DTED  format  was  recommended  especially  highly;  existing  software  is  capable  of  supporting 
both  graphic  displays  and  such  analyses  as  intervisibility  studies,  line-of-sight  calculations, 
terrain  masking,  mobility  analyses,  and  so  forth. 

However,  in  spite  of  the  desire  expressed  by  participants  for  arrayed  elevation  data, 
participants  also  stressed  that  an  arrayed  elevation  database  must  correlate  exactly  with  the 
feature  data  on  the  ONC  charts  from  which  the  majority  of  the  DCW  data  were  to  be  extracted 
(which  would  entail  a  review  of  the  positions  of  all  feature  data).  Since  available  array 
elevation  data  sources  were  not  correlated  with  ONC  source  documents,  correlation  of  arrayed 
data  with  feature  daf?  clearly  represented  a  significant  upscope  for  the  DCW  project 
Therefore,  after  the  Design  Concept  Review  (DCR),  the  scope  of  the  elevation  study  was 
directed  to  be  expanded  to  include  a  preliminary  investigation  of  the  feasibility  of  producing  an 
arrayed  data  set  from  both  the  ONCs  themselves  and  from  other  data  sources. 

2.3.2.4  Evaluation  of  Feasibility  of  Developing  Array  Data  from  ONCs 

To  evaluate  the  feasibility  of  developing  array  elevation  data  from  the  ONCs,  a  feasibility  study 
was  conducted  to  do  the  following: 

■  Define  a  sample  array  data  area  by  latitude  and  longitude  and  recommend  the  proper 
horizontal  and  vertical  intervals  for  the  array. 

■  Evaluate  the  impact  of  the  currently  recommended  tile  structure  on  the  elevation  array. 

■  Recommend  a  file  structure  for  the  proposed  array  data. 

■  Determine  how  to  code  the  elevation  values. 

■  Estimate  the  amount  of  the  data  storage  space  necessary  for  array  data  developed  for  the 
entire  database. 

2. 3.2.5  Recommendations 

The  recommendations  concerning  the  inclusion  and  portrayal  of  elevation  data  for  the  DCW 
were  as  follows.  ONC  elevation  data  were  recommended  as  the  source  data  for  the  DCW  (it 
was  recommended  that  the  DCW  not  make  use  of  any  elevation  data  external  to  the  ONCs). 

The  data  were  to  include  all  1,000- foot  contour  data;  all  supplemental  or  intermediate  ONC 
contour  data,  including  form  lines  and  approximate  contours;  and  all  ONC  spot  elevations  (land 
and  water).  It  was  further  recommended  that  contour  bands/polygons  be  prepared  for  all 
1, 000-foot  contours  and  that  ONC  contour  anomalies  be  given  special  handling. 
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The  handling  recommended  for  contour  anomalies  was  to  use  polygons  to  define  all  areas 
where  contours  either  were  not  present  or  did  not  conform  to  standard  definitions;  to  use 
polygons  for  closure  of  contours;  and  to  use  meridians  and  parallels  approximating  the  ONC 
sheet  edges  both  to  connect  and  to  close  contours  and  contour  bands.  Contour  connectors 
were  to  be  appropriately  attributed. 

The  study  also  indicated  that  contours,  contour  bands  (polygons),  and  spot  elevation  should  be 
implemented  in  the  DCW  product  in  accordance  with  the  VPF  structure  and  tiled  in  accordance 
with  DCW  tiling  study  recommendations.  The  DCW  elevation  data  were  thus  not  presented  in 
an  arrayed  form  primarily  due  to  the  necessity  for  a  significant  project  upscope  if  this  was 
attempted. 

2.3.3  Tile  Design  Study 

2.3.3. 1  Introduction 

Because  of  equipment  limitations,  such  as  the  availability  of  Random  Access  Memory  (RAM) 
or  software  limits,  a  spatial  database  greater  than  a  certain  size  becomes  too  large  to  manage  as 
a  single  unit  and  must  be  partitioned  into  smaller  units.  The  mechanism  for  breaking  a  large 
spatial  database  into  smaller  units  is  termed  tiling,  or  partitioning.  Because  of  the  size  of  the 
DCW  (about  1.7  gigabytes  of  digital  data),  a  tiling  scheme  needed  to  be  designed  for  it 

Two  tiling  schemes  were  considered  for  selection,  adaptive  and  fixed.  In  an  adaptive-tiling 
scheme,  tile  size  varies  according  to  data  density  (tiles  are  smaller  where  data  are  dense). 
Adaptive  tiling  is  suited  to  spatial  databases  with  great  variations  in  data  density.  In  a  fixed- 
tiling  scheme,  the  physical  area  of  partition  is  set  and  the  volume  of  data  within  it  is  allowed  to 
vary. 

The  tile  design  study  was  undertaken  to  explore  the  best  way  to  partition  the  DCW  database. 
The  results  of  the  study  were  reported  in  initial,  interim,  and  final  reports.  Data  density  varied 
greatly  from  one  ONC  sheet  to  another,  and  when  the  tiling  study  was  begun,  adaptive  tiling 
was  believed  to  be  preferable  to  fixed  tiling.  It  was  believed  that  adaptive  tiling  would  permit 
superior  performance.  However,  as  the  DCW  evolved,  it  became  clear  that  the  value  of 
managing  variations  in  density  would  have  to  be  weighed  against  the  disadvantages  of  adaptive 
tiling  for  production  and  for  use  of  the  DCW  with  other  products  that  use  fixed  filing  (such  as 
DTED).  Fixed  tiling  also  provided  a  consistent  framework  for  other  ongoing  studies  such  as 
the  geographic  organization  study. 

By  the  time  Prototype  4  was  released,  the  recommendation  for  the  tiling  scheme  had  shifted 
from  adaptive  to  fixed.  Fixed  tiling  was  implemented  in  Prototype  4  with  two  implementations 
of  tiling  sizes:  5  by  5  degrees  and  3  by  3  degrees.  Part  of  the  evaluation  of  Prototype  4 
involved  determining  the  most  advantageous  tiling  size. 

It  was  indicated  in  the  study  that  for  a  product  with  one  dominating  constraint,  the  tiling 
scheme  selected  must  optimize  for  that  constraint  However,  a  general-purpose  database  like 
the  DCW  has  no  dominating  constraint  and  must  therefore  utilize  a  tiling  scheme  that  is 
satisfactory  from  the  standpoint  of  all  constraints  on  the  database.  Six  special  requirements  for 
the  DCW  filing  scheme  were  identified  in  the  study. 
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■  The  selected  scheme  must  cover  the  entire  surface  of  the  globe. 

■  It  must  be  possible  to  implement  the  scheme  effectively;  the  tiling  scheme  must  be 
integral  to  the  database,  yet  the  implementation  of  the  scheme  must  be  unaffected  by 
(and  devoid  of  impact  on)  the  sequence  of  database  production. 

■  The  tiling  scheme  must  conform  to  VPF. 

■  The  tiling  scheme  must  be  usable  with  both  existing  and  future  products. 

■  The  tiling  scheme  must  allow  whole  tiles  to  be  placed  on  a  single  CD-ROM. 

■  The  tiling  scheme  must  be  compatible  with  the  indexing  scheme  used  for  the  DCW. 

2. 3.3.2  Evaluation  of  Adaptive  and  Fixed  Tiling 

Adaptive  Tiling 

To  implement  adaptive  tiling,  one  needs  to  estimate  the  volume  of  data  for  a  certain  map  sheet 
to  see  if  the  volume  exceeds  a  certain  threshold.  If  so,  partitioning  is  required.  If  partitioning 
is  done,  the  data  volume  for  each  resulting  quadrant  of  the  map  sheet  is  estimated  to  see  if  the 
data  volume  of  any  quadrant  still  exceeds  the  threshold.  If  so,  that  quadrant  must  be 
partitioned  again.  The  process  continues  until  no  quadrant  (tile)  exceeds  the  maximum 
allowable  data  volume.  The  final  step  is  to  assemble  the  map  sheet  with  adjacent  sheets. 

The  results  of  the  study  indicated  that  adaptive  tiling  is  highly  sensitive  to  data  content  and  that, 
through  the  data  volume  estimate  procedure,  it  is  closely  coupled  to  changes  in  data  content  and 
representation.  In  addition,  the  final  global  tiling  scheme  cannot  be  determined  until  the  last 
map  sheet  is  automated  and  the  final  partition  is  produced.  This  characteristic  represented  the 
biggest  obstacle  to  developing  a  scheme  for  the  geographic  organization,  or  allocation  of  tiles, 
to  the  CD-ROMs.  In  addition,  by  adopting  an  adaptive  tiling  scheme,  the  large  effort 
associated  with  the  production  process  of  tiling  would  have  needed  to  be  delayed  until  all 
automation  was  complete.  The  DCW  production  schedule  would  not  support  this  constraint. 

Fixed  Tiling 

Fixed  tiling  was  the  other  option  for  tiling  the  DCW  database.  Fixed  tiling  is  the  opposite  of 
adaptive  tiling  in  that  tile  size  is  the  same  throughout  an  area.  Furthermore,  once  defined,  the 
size  of  fixed  tiles  remains  the  same  throughout  subsequent  processing. 

As  with  adaptive  tiling,  implementing  fixed  tiling  requires  both  the  development  of  partitioning 
procedures  and  the  determination  of  the  unit  of  measure  to  be  used  to  define  the  partition. 
However,  unlike  the  adaptive  method,  these  determinations  can  be  made  before  production. 
Systematic  partitioning  along  a  longitude-latitude  grid  is  a  common,  well  known  form  of 
spatial  division,  and  this  type  of  partitioning  was  used  for  the  DCW  database. 

Once  tile  size  is  determined,  fixed  tiling,  unlike  adaptive  tilmg,  does  not  require  the  evaluation 
of  data  content  A  grid  can  be  mathematically  generated  quickly  and  accurately  for  all  or  part  of 
the  globe.  The  tiling  can  begin  as  soon  as  the  first  layer  within  the  map  sheet  is  finished,  and 
any  map  sheet  can  be  automated  and  tiled  immediately  (without  assessing  the  content  of 
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incomplete  tiles).  This  degree  of  independence  between  the  tiling  scheme  and  the  production  of 
data  is  advantageous,  since  the  sequence  of  map  sheet  processing  is  not  affected  by  the  tiling 
procedure.  Thus,  by  comparison  with  adaptive  tiling,  fixed  tiling  does  not  adversely  affect  the 
production  process. 

The  tile  design  study  indicated  that  it  was  important  to  determine  tile  size  before  implementing 
the  tiling  scheme.  Determining  a  fixed  tile  size  is  a  function  not  only  of  data  content  but  also  of 
the  characteristics  of  the  software  and  of  the  database  storage  media  (CD-ROM,  for  the  DCW 
database).  The  preliminary  CD-ROM  indexing  studies  discussed  in  Section  2.3.4  indicated 
that  query  response  time  was  effectively  linear  for  a  given  range  of  geographic  extents,  which 
correspond  to  a  range  of  data  content  This  meant  that  within  a  certain  range  of  geographic 
extents,  query  process  times  were  linearly  related  to  the  number  of  features  for  a  given  feature 
type.  The  objective  was  to  select  a  tile  size  that  would  allow  data  volumes  to  stay  within  the 
linear  range.  The  two  fixed  tile  sizes  suggested  were  3  by  3  degrees  and  5  by  5  degrees. 

These  two  spatial  extents  corresponded  closely  to  the  lower  and  upper  file  size  range  limits 
reported  in  the  indexing  studies. 

The  final  tile  size  selected  was  5  by  5  degrees.  The  selection  was  based  on  the  careful 
evaluation  and  determination  of  data  volume,  software  functionality,  the  capabilities  of 
secondary  storage  devices,  production  constraints,  database  maintenance,  geographic 
organization,  the  potential  incorporation  of  other  products,  and  user  needs. 

2.3.3.3  Summary  and  Recommendations 

The  study  report  recommended  fixed  tiling  as  best  suited  to  the  DCW  database.  Fixed  tiling 
was  simple,  stable,  easy  to  understand  and  create,  and  could  be  implemented  independent  of 
database  construction  and  maintenance.  A  decision  to  use  fixed  tiling  also  enabled  other  project 
activities,  including  the  development  of  the  geographic  organization  of  the  database,  software 
functionality,  and  data  structure,  to  proceed  independently  of  the  tiling  process. 

2.3.4  Indexing  Studies 

The  DCW  indexing  studies  were  made  to  investigate  methods  to  allow  efficient  DCW  database 
queries,  given  the  constraints  of  the  hardware  and  software  environment.  (See  Section  2.5.3 
for  a  description  of  this  environment.)  The  studies  were  initiated  in  July  1990  and 
implemented  and  modified  in  Prototypes  2  to  4. 

2.3.4.1  Introduction 

The  objective  of  the  indexing  studies  was  to  evaluate  and  propose  methods  for  implementing 
database  queries  of  four  types:  spatial  queries,  thematic  queries,  queries  through  the  gazetteer 
(or  place  name  index),  and  queries  based  on  coverage.  The  indexing  designs  were  adapted  and 
modified  through  the  evaluation  of  the  prototypes  according  to  the  needs  of  the  software  and  of 
VPF. 

The  original  approach  taken  to  the  study  was  to  use  additional  indexes  to  solve  such  problems 
as  polygon  shading.  However,  the  indexing-only  approach  caused  poor  performance  because 
it  could  not  deal  adequately  with  the  complex  interrelationship  between  VPF,  the  VPFVIEW 
software,  the  DCW  data  content,  and  the  minimum  hardware  configuration.  For  example, 

VPF  stated  that  polygon  data  must  be  implemented  in  four  related  files.  Reading  these  four 
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files  simultaneously  for  polygon  shading  was  very  slow.  To  reduce  data  access  time,  a  special 
shading  index  was  tested  within  Prototype  3  in  which  the  necessary  information  for  shading 
was  collected  in  a  single  file.  Unfortunately,  this  implementation  violated  a  functional  VPF 
requirement  that  there  be  no  redundant  data,  so  the  index-only  approach  was  abandoned. 

To  solve  the  performance  problem,  performance  studies  were  then  undertaken  to  examine  all 
aspects  of  performance  and  to  implement  solutions  using  multiple  techniques.  Indexing  was 
one  of  the  techniques  used  to  speed  up  data  access  times;  others  included  hardware  drivers, 
software  techniques,  and  user  query  methods.  The  various  techniques  were  implemented  and 
evaluated  in  a  cyclic  process  that  included  the  implementation  of  the  techniques  currently 
thought  best  (optimization),  testing,  analysis,  and  refinement.  The  cyclic  process  was 
followed  through  three  prototypes,  beginning  with  Prototype  2. 

Because  VPF  was  constantly  evolving,  final  solutions  could  not  be  developed  until 
Prototype  4.  Optimization  work  in  Prototypes  2  and  3  concentrated  instead  upon  the  basic 
attributes  of  the  hardware  and  software  system  components  (the  CD-ROM  drive,  the  minimum 
hardware  platform,  the  C  programming  language,  and  the  software  design).  This  performance 
analysis  process  ended  in  February  1991,  with  impressive  improvement  in  some  areas.  The 
functionality  requirements  stated  earlier  (for  spatial  queries,  thematic  queries,  etc.)  were  met  by 
software  functions  implemented  in  VPFVIEW  as  follows; 

■  Spatial  query:  spatial  query  index 

■  Thematic  query:  theme  and  feature  selection  menus  (thematic  index) 

■  Gazetteer  query:  gazetteer  index 

■  Query  based  on  coverage:  Browse  map  (coverage  index) 

As  a  summary,  the  indexing  studies  were  initially  limited  to  investigating  indexing  techniques 
for  the  CD-ROM  data  storage  medium.  The  studies  showed  that  optimizing  the  indexing 
techniques  for  the  CD-ROM  itself  failed  to  address  many  of  the  complex  issues  that  affected 
the  interaction  of  the  DCW  software  and  database  (i.e.,  performance).  Therefore,  the  scope  of 
the  studies  gradually  expanded  to  include  the  effects  on  data  access  of  other  aspects  of  system 
design,  including  the  demands  of  VPF,  the  functionality  of  the  software,  and  the  characteristics 
of  the  minimum  configuration  hardware.  The  CD-ROMs  that  represented  the  scope  of  the 
original  studies  were  studied  as  an  integral  part  of  the  hardware  environment 

2.3.4,2  Methodology  Used  for  Performance  Testing 

The  analysis  and  test  methodology  had  four  steps:  optimization,  testing,  analysis,  and 
refinement  Optimization  was  the  incorporation  of  performance  improvements  and  indexing 
designs  into  the  software.  Testing  was  the  process  of  implementing  the  optimized  design  into 
the  system;  it  involved  the  measurement  of  many  different  aspects  of  the  software  and  revealed 
any  improvement  due  to  preceding  optimizations  and  indexes.  Analysis  was  done  during  and 
after  testing  to  detect  improvement.  Refinement  represented  the  transformation  of  analysis  into 
the  improvement  of  the  software,  hardware,  and  data  structures.  These  four  steps  represented 
the  overall  testing  structure  that  was  applied  to  Prototypes  2  to  4. 
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2.3.4.3  Test  Results 
Prototype  2  Results 

Prototype  2  represented  the  first  round  of  testing,  and  the  prototype  software  and  database 
were  on  a  floppy  disc,  rather  than  CD-ROM.  Therefore,  a  series  of  basic  hypotheses  about  the 
functioning  of  the  CD-ROM  at  the  file  level  were  defined  and  tested. 

Optimization.  Four  proposed  index  structures  were  carefully  sized  so  as  to  fit  in  RAM  or  on 
the  hard  disk.  These  four  indexes  were  the  gazetteer  index,  master  disc  spatial  extent  index, 
current  CD  spatial  and  thematic  index,  and  master  thematic  index.  The  gazetteer  index  was  a 
simple  list  showing  place  name  and  latitude/longitude.  The  gazetteer  function  skipped  the 
spatial  index  and  read  the  gazetteer  index  directly  to  print  out  name  and  location  as  text  The 
master  disc  spatial  extent  index  was  a  list  of  the  contents  of  each  disc.  The  current  CD  spatial 
and  thematic  index  was  a  summary  of  the  data  contained  in  each  layer  of  each  tile.  It  was 
intended  to  give  the  user  an  immediate  idea  of  the  contents  of  an  area.  The  master  thematic 
index  provided  summary  thematic  information  for  all  the  tiles  in  the  database;  it  was  provided 
to  facilitate  cross-disc  queries  or  to  build  adaptive  menus  for  selected  areas  not  on  the  current 
disc.  (Because  the  number  of  discs  needed  for  the  DCW  database  was  four  instead  of  the 
twenty-five  originally  thought  necessary,  this  index  was  later  deleted  as  unnecessary.) 

Testing.  Since  there  was  no  actual  CD-ROM  to  test,  all  tests  were  carried  out  by  using  a 
CD-ROM  publishing  system,  a  series  of  programs  designed  to  simulate  different  players  on 
the  CD-ROM  production  premastering  hardware. 

Analysis  and  Refinement.  The  analysis  of  the  test  results  revealed  the  following; 

■  File  access  was  faster  for  directories  of  less  than  forty  names. 

■  Increasing  the  RAM  buffer  gave  faster  access  only  on  very  large  directories  (those  with 
more  than  thirty  names). 

■  File  access  was  faster  for  files  at  the  beginning  of  a  CD-ROM  disc. 

■  Sequential  access  to  adjoining  files  was  faster  than  nonsequential  access. 

■  The  performance  of  different  CD-ROM  drive  models  manufactured  by  different 
vendors  differed  significantly.  Three  drives  were  selected  for  further  study  as 
representative  of  a  range  of  drives  of  reasonable  performance. 

Prototype  3  Results 

Optimization.  The  system  optimizations  based  upon  the  findings  from  Prototype  2  were  to 
keep  all  directories  less  than  thirty  names;  to  arrange  files  in  sequential  order  (the  order  in 
which  they  were  read);  and  to  test  all  candidate  tiling  schemes. 

■Testing.  Testing  was  done  on  the  minimum  configuration  machine  (80286  model  machine 
with  peripherals).  The  CD-ROM  drive  was  tested.  To  obtain  additional  information  about  the 
software-platform  interaction,  a  more  powerful  80386  platform  was  also  tested. 
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Analysis  and  Refinement.  The  overall  drawing  times  for  Prototype  3  were  two  to  three  times 
as  fast  for  Prototype  2.  The  time  savings  was  due  partly  to  the  optimization  described  above 
and  partly  to  software  additions  and  improvements  in  areas  that  could  not  be  tested  in 
Prototype  2. 

The  difference  in  performance  (draw  times)  for  data  accessed  from  the  CD-ROM  and  data 
accessed  from  the  hard  disk  were  more  pronounced  on  the  faster  platforms.  This  result 
revealed  that  the  platform  was  the  limiting  factor  on  performance  and  not  the  CD-ROM  media. 

A  tiling  test  was  conducted  to  determine  the  tile  size  that  optimized  performance  and  storage 
efficiency  while  incurring  the  least  storage  and  performance  overhead.  The  tests  revealed  that 
1-by- 1-degree  tiles  generally  involved  a  performance  penalty  and  definitely  carried  a  high 
storage  overhead.  At  the  larger  end  of  the  tile  size  scale,  8-by-  14-degree  tiles  also  carried  a 
performance  penalty,  since  large-file  search  times  were  so  poor. 

Three  hardware  models  were  tested  to  identify  the  platform  and  media  characteristics  that 
affected  performance.  The  tests  showed  that  platform  speed  was  affected  by  raw  clock  speed, 
data  bus  width,  internal  cache  memory,  and  the  integration  of  the  platform’s  components 
(CPU,  bus,  cache,  RAM,  and  media).  Media  speed  was  affected  by  average  access  time, 
nominal  bulk  data  transfer  rate,  fragmentation,  latency,  and  interleaving. 

Prototype  4  Results 

Optimization.  Optimizations  implemented  and  tested  in  Prototype  4  included  the  following: 

■  Long  seeks  were  removed,  the  largest  files  were  reduced  to  less  than  1  megabyte  (MB), 
and  concurrent  hard  disk  scans  were  implemented,  where  possible,  for  large  files  that 
had  to  be  read  together. 

■  Files  were  arranged  in  the  order  read,  with  index  files  immediately  before  their  data. 

■  Each  file  was  opened  and  read  only  once.  Files  read  many  times  were  put  into  RAM  or 
hard  disk. 

■  Index  files  were  put  into  RAM. 

■  Directories  were  located  immediately  before  their  files. 

■  Directories  were  kept  at  less  than  forty  names. 

■  Primitive  files  were  read  sequentially,  in  a  single,  forward  pass  (except  for  polygons). 

■  Low  level  input/output  code  was  sped  up  to  reduce  latency. 

Testing.  The  testing  of  Prototype  4  included  the  following  procedures:  source  code  analysis, 
the  running  of  specially  marked  versions  of  software,  the  examination  of  raw  program  run 
data,  the  running  of  database  management  programs,  the  generation  of  output  tables,  the 
generation  of  analysis  tables,  stopwatch  verification,  the  generation  of  production  quality 
control  reports,  and  the  generation  of  text  reports. 


September  1992 


2-21 


Chapter  2  -  Phase  I — Design  and  Prototyping 


The  source  code  was  analyzed  to  identify  software  input  and  output  routines,  database-specific 
routines,  and  any  potential  trouble  areas  for  performance.  Specific  codes  were  added  to  these 
areas  to  report  the  time  taken  and  the  number  of  loops  called. 

Specially  marked  versions  of  software  were  run  to  isolate  and  detect  the  most  time-consuming 
parts  of  the  software.  The  end  result  was  the  production  of  precise  timing  figures  down  to  the 
finest  subdivisions  of  the  program  (the  precision  of  the  timing  figures  was  limited  only  by  the 
timer  resolution  of  the  hardware  itself). 

Raw  program  run  data  were  output  data  contained  in  an  output  file  that  listed  the  program 
marks  identifying  each  part  of  the  program  in  sequence.  These  raw  data  were  useful  for 
checking  a  run  step  by  step  to  see  which  commands  occurred  in  which  order  and  how  long 
each  command  took. 

Database  management  programs  were  written  and  used  to  provide  automated  database  handling 
of  the  output  data  files.  These  programs  were  run  on  an  80386  computer;  output  was  accepted 
over  a  serial  link  from  the  test  platform.  This  procedure  allowed  tests  to  be  run  uninterrupted 
while  their  results  were  being  processed. 

Output  tables  were  generated;  they  contained  three  parts.  The  first  part  was  a  summary  of  total 
data  count  and  total  time  for  each  activity.  The  second  part  was  a  frequency  analysis  of  each 
activity,  which  was  used  as  a  statistical  tool  to  monitor  and  control  timer  resolution  problems. 
The  third  was  a  list  of  the  sequential  file  positions  of  the  files  used  to  monitor  the  number  of 
nonsequential  seeks  in  each  file. 

Analysis  tables  were  output  tables  collated  by  overall  function  in  order  to  collect  total  times  for 
each  VPF  file  structure  or  DCW  function. 

Stopwatch  verification  was  used  to  provide  real-time  verification  of  the  program  times 
produced  at  each  step  in  the  process.  They  were  especially  useful  for  evaluating  the  analysis 
tables. 

Production  quality  control  reports  were  used  as  an  independent  verification  of  the  database 
content  in  each  of  the  test  data  selections. 

Text  reports  were  used  to  determine  the  database  content  of  each  test  data  selection,  in  order  to 
tie  the  times  observed  to  real  data  features,  and  to  ensure  that  the  different  ways  the  tests  run 
continued  to  utilize  identical  sets  of  data. 

Analysis  and  Refinement.  The  performance  of  Prototype  4  was  compared  to  that  of 
Prototype  3.  Edge  drawing  was  faster,  especially  for  elevation  data.  However,  face  drawing 
was  many  times  slower  and  alone  accounted  for  an  overall  decrease  in  performance. 

Prototype  3  used  a  CD-ROM-optimized,  redundant  data  index  to  shade  polygons.  This 
structure  violated  VPF  rules,  and  it  was  replaced  in  Prototype  4  by  a  nonoptimized  four-file 
polygon  structure. 

An  80486  class  machine  was  included  in  the  Prototype  4  testing.  The  use  of  an  80386  or 
80486  instead  of  an  80286  class  machine  with  the  same  CD-ROM  drive  and  controller 
markedly  increased  CD-ROM  performance.  However,  the  performance  of  the  80486  was  no 
better  than  that  of  the  80386,  even  though  the  80486  hard  disk  was  almost  twice  as  fast.  This 
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was  consistent  with  a  CPU  limitation  rather  than  a  media  limitation.  The  hard  disk  times  all 
appeared  much  faster  than  the  CD-ROM,  which  might  tend  to  imply  that  the  CD-ROM  media 
was  a  limiting  factor  after  all.  In  the  Prototype  4  analysis,  it  was  also  found  that  the  media 
could  be  constrained  by  the  method  of  file  access. 

As  in  the  Prototype  3  testing,  a  software  model  breakdown  was  used  to  evaluate  the 
functioning  of  the  DCW  application  software.  The  software  model  times  revealed  that  the  tile 
structure  was  being  used  inefficiently.  An  immediate  optimization  was  attempted  in  which  a 
few  small  changes  were  made  to  the  software;  the  improvement  in  the  tile-dependent  times  was 
immediately  apparent,  illustrating  the  power  of  software  modeling  and  test  methodology  tools 
developed  during  Prototype  4. 

The  question  of  the  optimum  tiling  scheme  for  performance  was  revised  in  Prototype  4.  Two 
final  candidate  tiling  schemes,  3  by  3  degrees  and  5  by  5  degrees,  were  selected  and  tested  in 
this  prototype.  Performance  times  for  the  5-by-5-degree  tiling  scheme  were  reasonable.  By 
comparison  with  the  3-by-3-degree  tiles,  there  was  no  performance  degradation  when  drawing 
small  or  large  windows,  and  storage  efficiency  was  better. 

2.3.4.4  Summary 

The  original  objective  of  the  indexing  studies  was  to  evaluate  the  indexing  of  the  CD-ROMs 
only  and,  in  effect,  to  provide  optimum  capability  and  data  access  speeds.  During  the  studies, 
it  was  found  that  the  original  approach  failed  to  address  adequately  the  overriding  concern  of 
performance.  Performance  problems  were  found  to  be  caused  mainly  by  the  interaction  of  the 
hardware  and  software  components  of  the  DCW.  Optimization  could  not  be  achieved  by 
focusing  on  one  performance  component,  like  CD-ROM  indexing  or  software  functionality. 
The  solution  was  to  adopt  an  integrated  approach  in  which  all  project  goals  and  all  hardware 
and  software  components  were  considered. 

A  methodology  was  developed  and  applied  to  Prototypes  2  through  4  to  address  and  resolve 
the  indexing  and  performance  problems.  The  methodology  included  the  four-step  cycle  of 
optimization,  testing,  analysis,  and  refinement.  The  results  of  each  prototype  were  examined 
and  used  to  refine  the  indexing  and  performance  of  the  next. 

2.3.5  Geographic  Organization  Study 

The  geographic  organization  study  was  undertaken  to  define  the  optimal  distribution  of  data  for 
storage  on  the  CD-ROM  media.  The  research  was  performed  in  two  phases  described 
respectively  in  the  Initial  Geographic  Organization  Study  and  the  Final  Geographic 
Organization  Study.  The  initial  study  discussed  geographic  organization  in  terms  of  a  number 
of  factors,  including  traditional  geographic  regional  groupings.  The  final  version  of  the  study 
integrated  data  volume  and  scheduling  issues  in  the  discussion.  The  study  results  and 
recommendations  were  made  in  the  final  study. 

2. 3.5.1  Objective 

The  DCW  database  contains  about  1,700  MB  of  data,  which  is  well  in  excess  of  the  capacity  of 
a  single  CD-ROM.  Therefore,  the  DCW  database  had  to  be  partitioned  into  distinct  subsets  on 
individual  CD-ROMs,  while  still  retaining  the  characteristics  of  a  single  database.  The 
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objective  of  the  geographic  organization  study  was  to  define  the  final  physical  organization  of 
the  DCW  database  on  the  CD-ROM  storage  media. 

2.3.S.2  Constraining  Factors 

A  number  of  factors  were  considered  in  determining  the  optimum  distribution  of  data  among 
CD-ROMs,  including  traditional  cartographic  or  cultural  themes,  the  manner  in  which  a  user 
would  interact  with  the  database  (applications),  data  volumes,  and  project  scheduling. 

Logical  Groupings  of  the  Geographic  Areas 

The  study  indicated  that  the  DCW  geographic  organization  should  be  based  in  part  on 
traditional  views  of  geography.  Prevalent  themes  in  global  geographic  groupings  include 
country  borders,  physiographic  regions,  and  cultural  (language  or  religious)  groups.  It  was 
also  desirable  for  the  DCW  geographic  organization  to  reflect  contemporary  factors,  such  as 
economic  relationships  and  geopolitics. 

Data  Volume 

Data  volume  was  one  of  the  important  factors  to  be  considered  in  the  division  of  DCW 
geographic  organization.  Each  CD-ROM  allows  for  the  practical  storage  of  500  MB  of  data. 
Any  proposed  geographic  organization  had  to  work  within  this  physical  media  constraint 

Applications  Software 

The  DCW  package  includes  the  VPFVIEW  software  package  that  allows  the  user  to  view  the 
database  on  a  personal  computer.  The  software  allows  the  user  to  load  and  unload  discs  as  the 
area  of  interest  moves  across  the  data  boundaries  between  discs.  The  study  acknowledged  the 
usefulness  of  this  capability  but  found  working  on  a  single  disc  to  be  most  desirable  because  of 
the  flexibility  it  affords  the  user  engaged  in  map  composition  and  data  review.  For  this  reason, 
"overlap  areas"  were  created  between  discs  (some  data  were  duplicated  on  more  than  one  disc) 
to  allow  continuity  of  anticipated  areas  of  interest  The  desirability  of  creating  overlap  areas 
was  further  supported  by  the  fact  that  the  DCW,  as  a  1:1, 000,000-scale  product  is  perhaps 
best  suited  for  regional  applications,  rather  than  global  or  continental  ones;  the  density  and 
volume  of  DCW  data  far  exceed  those  that  can  be  analyzed  or  displayed  at  global  or  continental 
scales. 

Another  characteristic  of  the  DCW  database  is  that  it  can  be  used  outside  the  DCW  application 
software  environment,  on  user  GIS  and  digital  mapping  systems.  If  they  are  used  in  this  way, 
the  DCW  CD-ROMs  essentially  act  as  a  data  storage/transfer  media,  and  it  therefore  becomes 
desirable  for  the  data  to  be  contained  on  as  few  discs  as  possible,  and  for  the  discs  to  be  packed 
in  space-efficient  containers. 

Scheduling 

Because  of  the  demanding  production  schedule,  the  premastering  and  mastering  of  the  first 
CD-ROM  were  started  while  other  portions  of  the  database  were  still  in  the  early  stages  of 
production.  As  a  result,  the  geographic  organization  was  affected  to  some  extent  by  the 
production  schedule.  However,  an  effort  was  made  to  minimize  these  effects  on  the  DCW's 
final  geographic  organization. 


2-24 


Development  of  the  DCW 


Chapter  2  -  Phase  I — Design  and  Prototyping 


2.3.5. 3  Final  Organization 

The  Final  Geographic  Organization  Study  recommended  that  four  CD-ROMs  be  used  and  that 
they  contain  the  following  four  geographic  areas  of  the  globe:  (1)  North  America,  (2)  Europe/ 
Northern  Asia,  (3)  South  America/ Africa/ Antarctica,  and  (4)  Southern  Asia/Australia.  This 
geographic  organization  was  based  first  on  logical  geographic  groupings;  common 
physiographic  and  cultural  regions  were  preserved  whenever  possible.  The  area  of  overlap  on 
each  disc  was  based  primarily  on  cultural  and  geopolitical  associations.  Nondata  tiles  (tiles 
containing  open  ocean)  were  carefully  assigned  to  encompass  major  regional  ocean  basins  and 
other  features.  This  last  criterion  was  developed  to  support  possible  future  bathymetric  data 
enhancements  of  the  database. 

Each  disc  contains  approximately  430  MB  of  data,  thereby  roughly  equalizing  the  distribution 
of  data  volume  on  the  discs.  The  data  distribution  allows  for  significant  additional  data  to  be 
added  to  future  editions  of  the  DCW  product  without  altering  the  DCW  geographic 
organization. 

2.3.6  Symbolization  Study 

The  symbolization  study  was  undertaken  to  determine  how  best  to  display  the  DCW  with 
VPFVIEW.  Tasks  included  identifying  symbolization  requirements  and  constraints  and 
designing  and  implementing  appropriate  symbol  sets  and  tables.  The  study  also  identified 
some  ways  users  could  optimize  display  quality. 

2.3.6  1  Symbolization  Requirements 

Because  the  DCW  was  created  from  ONCs,  one  goal  of  the  symbolization  design  was  to 
maintain  the  graphic  portrayal  of  ONC  symbology  where  feasible,  even  though  ONC 
symbology  was  not  designed  for  digital  display.  According  to  their  comments  on  the 
prototypes,  users  expected  the  DCW  to  retain  the  ONC  symbology.  However,  the  traditional 
design  elements  needed  to  be  compatible  with  the  capabilities  of  an  interactive  electronic 
display.  For  example,  the  symbology  had  to  be  fully  compatible  with  the  changing  scales  that 
would  result  when  users  employed  the  "zoom  in"  and  "zoom  out"  commands. 

2.3.6.2  Symbolization  Constraints 

The  major  constraints  on  the  design  of  the  display  symbology  were  the  resolution  of  the 
minimum  configuration  monitor,  the  capabilities  of  the  C  graphics  libraries,  and  the  capabilities 
of  VPFVIEW  (see  Section  2.5.3  for  a  description  of  the  VPFVIEW  hardware  and  software 
environment).  Of  these  factors,  the  resolution  of  the  monitor  (12-inch  medium  resolution  color 
monitor  [EGA  640  x  30  resolution])  was  the  primary  constraint,  because  it  affected  the 
appearance  of  the  point  symbols,  linework,  area  patterns,  and  typography. 

The  C  programming  language  was  used  in  the  development  of  VPFVIEW.  The  basic  graphic 
symbology  of  the  C  graphics  libraries  was  another  major  constraint  on  the  development  of  the 
DCW  symbology,  especially  in  regard  to  line  weights  and  area  fill  patterns. 
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2.3.6.3  Symbolization  Implementation 

The  symbology  implemented  in  the  DCW  was  developed  throughout  the  prototyping  process. 
Initial  symbology  was  introduced  with  Prototype  3,  and  it  continued  to  evolve  through  and  past 
Prototype  4.  Comments  and  suggestions  on  Prototypes  3  and  4  were  incorporated  in  the  final 
DCW  symbol  sets. 

A  default  symbology  was  implemented  to  provide  the  user  with  an  immediate  and  adequate 
symbology  for  all  the  data  in  the  DCW.  ONC  symbols  were  retained  where  they  logically 
could  be.  However,  given  the  default  symbology  constraints,  VPFVTEW  was  enhanced  to 
allow  users  to  define  changes  in  the  symbology.  Within  VPFVIEW,  the  user  can  change  the 
symbols  used  for  point  and  line  features  and  has  access  to  a  sixteen-color  palette  and  three  text 
fonts.  These  functions  allow  users  to  support  a  specific  application  or  data  orientation  by 
resymbolizing  and  regrouping  features  for  clarity. 

2.3.6.4  Optimizing  Graphic  Displays 

In  addition  to  discussing  the  factors  that  led  to  the  symbolization  finally  implemented,  the 
symbolization  study  outlined  ways  users  could  optimize  display  quality.  Specifically,  it 
recommended  that  users  do  the  following: 

■  Display  as  few  features  as  possible. 

■  Since  color  is  the  only  usable  means  of  distinguishing  features  at  scales  smaller  than 
1:1,000,000,  reserve  color  for  significant  differentiations. 

■  Since  background  area  tints  make  text,  point,  and  line  symbols  difficult  to  read,  fill 
polygons  only  when  necessary. 

■  Relate  color  groupings  (by  hue)  and  progressions  (by  value  or  brightness)  to  feature 
groupings  (avoid  assigning  them  randomly). 

2.3.7  DCW  Error  Analysis 

An  error  analysis  for  the  spatial  data  in  the  DCW  database  was  performed  as  one  of  the  special 
studies  for  the  DCW.  The  study  was  stated  in  the  early  phases  of  production  and  completed  in 
February  1991.  The  following  summarizes  the  objectives  of  error  analysis,  the  methodology 
used  to  perform  the  study,  and  the  study  results  and  recommendations. 

2.3.7. 1  Objectives 

The  main  objective  of  the  DCW  error  analysis  was  to  compile  a  list  of  all  error  sources 
influencing  DCW  database  accuracy  and  to  perform  an  error  propagation  analysis.  This  study 
was  limited  to  the  positional  accuracy  of  the  automated  database  from  the  ONC  series.  Other 
accuracies,  including  those  pertaining  to  attribute  accuracy,  data  completeness  and  logical 
consistency,  and  quality  of  lineage,  were  not  included  in  the  study. 
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2.3.7.2  Requirements  for  the  DCW  Error  Analysis 

Typically,  error  propagation  analyses  for  spatial  data  require  an  analysis  of  all  positional  errors 
introduced  during  the  compilation  and  automation  of  the  spatial  data.  Positional  error  is 
defined  as  the  deviation  of  features  from  their  true  location  in  each  coordinate  direction,  where 
the  true  location  of  those  features  is  usually  derived  from  existing  sources  of  higher  accuracy  or 
from  a  field  surveying  check  of  higher  accuracy. 

Horizontal  accuracy  is  usually  stated  as  a  circular  error,  and  vertical  accuracy  as  a  linear  error, 
at  a  specified  confidence  level.  Linear  errors  are  used  to  express  the  vertical  error  in  the  Z- 
coordinate  direction.  Both  circular  and  linear  errors  are  derived  from  standard  deviations  in 
each  coordinate  direction.  In  accordance  with  these  conventions,  the  horizontal  position 
accuracy  in  the  DCW  error  analysis  was  represented  in  terms  of  circular  error,  and  the  vertical 
accuracy  was  represented  in  terms  of  a  linear  error,  both  at  a  90  percent  confidence  interval. 

As  indicated  in  the  error  analysis  study,  errors  were  introduced  during  each  of  the  mapping  and 
automation  processes.  Since  the  DCW  database  was  developed  based  on  the  ONC  series  and 
the  exact  ONC  chart  histories  were  unknown,  no  estimate  could  be  given  for  errors  introduced 
at  each  ONC  production  process.  However,  the  degree  of  error  introduced  into  the  DCW 
during  automation  was  estimated  by  measuring  the  displacement  of  points  from  their  true 
position  at  certain  steps  during  the  DCW  production  process.  Since  the  accuracy  of  an  original 
ONC  sheet  was  known,  an  overall  accuracy  for  the  same  DCW  module  could  be  obtained  by 
computing  the  root  sum  square  of  the  ONC  error  and  the  DCW  automation  error. 

It  was  presumed  that  if  the  errors  for  the  DCW  production  process  had  been  estimated  reliably, 
the  DCW  accuracy  derived  by  computing  the  root  sum  square  of  the  ONC  error  and  the  DCW 
automation  error  would  be  similar  in  magnitude  to  the  error  derived  by  comparing  DCW  data  to 
a  source  of  higher  accuracy.  Therefore,  the  following  requirements  were  established  for  the 
error  analysis  study: 

■  Overall  DCW  accuracy  was  to  be  estimated  through  an  independent  test  by  comparing 
DCW  data  to  a  source  of  higher  accuracy.  The  first  fully  automated  ONC  map  sheet, 
ONC  G-18,  was  chosen  for  this  part  of  the  analysis. 

■  Errors  introduced  into  the  data  by  basic  processing/automation  and  advanced  DCW 
•  processing  were  to  be  estimated.  The  basic  processing  of  DCW  data  included 

manuscript  preparation  and  drafting,  scanning  and  digitizing,  and  editing.  Advanced 
processing  included  the  projection  of  data  into  real-world  coordinates,  edge  matching, 
and  tiling.  Positional  errors  introduced  by  DCW  processing  were  to  be  estimated  by 
subjecting  test  data  containing  features  of  known  position  to  the  standard  DCW 
production  process  and  measuring  the  displacement  of  test  points  at  selected  steps 
during  the  proo  action  process. 

■  With  the  known  accuracy  of  ONC  G- 1 8  and  the  production  error  estimate,  a  DCW 
error  estimate  was  to  be  computed  through  a  root  sum  square  computation. 

■  Such  aspects  of  data  quality  as  completeness,  attribute  accuracy,  and  data  consistency 
were  not  addressed  in  this  report 
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2.3.7.3  Methodology  of  Determining  Positional  Accuracy 
Independent  Test  Using  Sources  of  Higher  Accuracy 

According  to  the  Merchant  1987  study  cited  in  the  error  analysis  report,  the  horizontal  and 
vertical  accuracy  of  spatial  data  can  be  determined  by  comparing  the  position  of  a  representative 
sample  of  well-defined  points  in  the  spatial  data  to  the  position  of  the  same  points  in  a  source  of 
higher  accuracy.  Sample  means  and  sample  standard  deviations  were  then  computed 
independently  for  all  three  coordinate  directions.  Once  these  quantities  were  known, 
conventional  hypothesis  testing  was  employed  to  determine  whether  the  spatial  data  contained 
systematic  error  or  whether  the  data  met  a  previously  established  accuracy  standard. 

USGS  l:24,000-scale  maps  were  selected  as  the  source  of  higher  accuracy.  For  a  source  of 
l:24,000-scale  map.  National  Map  Accuracy  Standards  specify  a  circular  error  of 
0.51  millimeter  at  map  scale  at  a  90  percent  confidence  level.  This  translates  to  an  error  of 
40.1  feet  at  ground  scale.  Spatial  data  of  1:1,000,000  typically  have  horizontal  errors  of 
between  1,640  feet  and  8,200  feet  associated  with  them,  depending  on  the  primary  use  of  the 
spatial  data.  Compared  with  an  error  of  this  magnitude,  an  error  of  40  feet  in  a  1:24,000 
USGS  sheet  is  virtually  negligible.  For  purposes  of  positional  accuracy  testing,  the  USGS 
map  sheets  were  therefore  considered  error  free. 

Accuracy  computations  were  based  on  a  total  of  thirty-nine  well-defined  test  points.  Test 
points  were  selected  from  two  scanned  and  two  manually  digitized  layers  (roads,  drainage, 
railroads,  utility  lines)  and  consisted  of  "between  layer"  as  well  as  "within  layer"  intersections. 
This  methodology  was  used  to  ensure  that  the  DCW  G-18  accuracy  statement  could  be 
considered  representative  for  all  database  layers. 

Estimation  of  Production  Errors 

In  order  to  estimate  production  errors,  a  test  graphic  of  dimensions  7.5  inches  by  7.5  inches 
was  developed.  The  test  graphic  contained  arbitrary  linear  features  and  simple  geometric 
features.  It  was  produced  as  a  single-precision  ARC/INFO  coverage  by  entering  all  feature 
coordinates  manually  through  the  keyboard.  Therefore,  the  position  of  all  features  in  the  test 
data  was  accurately  known. 

The  test  graphic  was  initially  subjected  to  the  basic  processing  steps  of  manuscript  preparation/ 
drafting,  scanning/digitizing,  and  editing.  A  sample  of  thirty  points  was  then  extracted,  and 
their  coordinates  were  compared  to  the  coordinates  in  the  original  test  graphic.  Basic 
production  errors  were  reported  as  a  circular  error  using  a  90  percent  confidence  interval.  The 
data  were  then  subjected  to  the  advanced  processing  steps  of  projection,  edge  matching,  and 
tiling.  Sample  points  were  again  extracted,  and  their  coordinates  compared  to  the  coordinates 
in  the  original  test  graphic,  in  order  to  determine  the  degree  of  error  introduced  during 
advanced  processing. 

2.3.7.4  Results  and  Discussion 

The  Circular  Map  Accuracy  Standard  (CMAS)  calculated  from  the  standard  deviations  in  the  X- 
and  Y-coordinate  directions  was  found  to  be  3,670  feet,  meaning  that  90  percent  of  all  well- 
defined  points  can  be  expected  to  be  within  3,670  feet  of  their  true  position.  This  compared 
with  an  error  of  2,500  feet  in  the  original  ONC  and,  through  a  root  sum  square  subtraction,  led 
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to  an  initial  production  error  estimate  of  1,104  feet  The  linear  map  accuracy  standard  for 
vertical  accuracy  of  the  automated  DCW  sheet  was  found  to  be  453  feet  The  comparable 
accuracy  given  for  the  ONC  G-18  was  500  feet  Since  the  vertical  error  in  the  DCW  G-18  did 
not  exceed  500  feet  it  was  concluded  in  the  study  report  that  during  DCW  production  no 
vertical  error  was  introduced  into  the  data. 

DCW  automation  errors  due  to  basic  processing,  when  translated  to  ground  scale  for  a  product 
of  scale  1:1,000,000,  was  found  to  be  1,099  feet  for  scanned  data,  1,277  feet  for  digitized 
data,  and  1,309  feet  for  data  that  were  first  manually  drafted  off  the  test  data  and  then  scanned. 
During  advanced  processing  steps,  very  little  additional  noticeable  positional  error  was 
introduced  into  the  test  data.  It  was  therefore  concluded  that  almost  all  positional  error  inherent 
in  the  DCW  production  process  was  introduced  during  basic  processing. 

This  was  not  unexpected,  since  advanced  processing  relied  mainly  on  automated  routines. 
Errors  during  advanced  processing  would  therefore  be  mainly  due  to  software  limitations  and 
possible  loss  in  coordinate  precision. 

Both  the  ARC/INFO  software  and  the  DCW  production  process  were  designed  to  minimize 
errors  from  these  sources.  The  results  of  advanced  processing  of  test  data  indicated  that  these 
objectives  had  indeed  been  achieved.  The  results  of  all  tests  showed  that  errors  introduced  into 
the  DCW  during  its  automation  were  of  acceptable  magnitude.  In  particular,  production  error 
estimates  for  each  automation  type  were  found  to  be  similar  in  magnitude  to  the  error  estimated 
from  the  independent  test  of  higher  accuracy. 

2.3.7.S  Conclusions  and  Recommendations 

The  following  conclusions  were  reached  as  a  result  of  the  study: 

■  The  horizontal  accuracy  of  the  DCW  automated  from  ONC  G-18  was  3,670  feet  at  a 
confidence  level  of  90  percent  This  was  compared  to  an  accuracy  of  3,500  feet 
(including  printing  error)  of  the  original  ONC  G-18. 

■  The  vertical  accuracy  of  the  DCW  automated  from  ONC  G-18  was  453  feet  at  a 
confidence  level  of  90  percent.  This  was  somewhat  less  than  the  500  feet  stated  as  the 
vertical  accuracy  for  ONC  G-18.  It  was  therefore  concluded  that  no  further  vertical 
error  was  introduced  into  the  elevation  data  during  DCW  production. 

■  Based  on  the  overall  accuracy  obtained  for  the  DCW  G-18  and  the  accuracy  published 
for  ONC  G-18,  DCW  production  error  was  initially  estimated  at  1,180  feet 

The  magnitude  of  the  error  introduced  into  DCW  data  during  the  DCW  production  process  was 
estimated  from  test  data,  and  was  measured  separately  for  digitized,  hand  drafted/scanned,  and 
scanned-only  coverages.  Results  indicated  the  following: 

■  The  errors  introduced  during  the  DCW  database  automation  were  of  acceptable 
magnitude. 

■  At  ground  scale,  production  errors  were  found  to  be  1 ,099  feet  for  scanned  coverages, 
1,277  feet  for  the  digitized  coverages,  and  1,309  feet  for  hand  drafted/scanned 
coverages  for  a  product  at  scale  1 : 1 ,000,000. 
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■  The  magnitude  of  production  errors  estimated  by  using  test  data  was  in  close 
correspondence  with  that  initially  estimated  (1,180  feet)  after  an  independent 
determination  of  the  accuracy  of  DCW  G- 1 8.  It  was  therefore  concluded  that  the  errors 
estimated  for  the  DCW  production  process  were  essentially  reliable. 

The  results  of  the  error  analysis  study  have  led  to  the  adoption  of  the  following 
recommendations  in  the  DCW  database  production: 

■  Since  the  errors  estimated  for  the  production  process  seemed  to  be  reliable,  the  accuracy 
of  individual  ONC  sheets,  in  conjunction  with  the  accuracy  of  the  DCW  production 
process,  should  be  used  to  derive  the  accuracy  of  each  DCW  production  module 
through  a  root  sum  square  calculation. 

■  During  DCW  production,  it  was  important  to  maintain  consistency  in  the  magnitude  of 
errors  introduced  into  DCW  data  automation.  A  procedure  was  therefore  implemented 
to  test  the  accuracy  of  the  DCW  production  process  at  selected  intervals. 


2.4  Vector  Product  Format  Military  Standard  Development 

The  major  goal  of  the  DCW  prototyping  phase  was  to  create  a  generic  standard  that  serves  as  a 
basis  for  multiple  digital  vector  mapping,  charting,  and  geodesy  products.  The  vector  product 
format  (VPF)  standard  was  developed  to  this  end.  In  fact,  although  the  DCW  database  stands 
as  a  monumental  achievement  of  the  DCW  project,  its  primary  initial  use  was  to  test  and  verify 
VPF  concepts. 

As  discussed  in  Section  2.2,  VPF  was  developed  during  the  DCW  prototyping  stage.  Work 
on  concepts  leading  toward  VPF  began  in  the  spring  of  1990.  A  complete  VPF  standard  was 
created  by  ESRI  in  the  spring  of  1991 ,  and  it  was  incorporated  into  Edition  1.0  of  the  Digital 
Geographic  Information  Exchange  Standard  (or  DIGEST)  in  June  of  1991.  DIGEST  is  now 
composed  of  two  standards,  its  original  "exchange"  version  and  also  VPF.  (Within  DIGEST, 
VPF  is  known  as  the  Vector  Relational  Format,  or  VRF;  VPF  and  VRF  are  identical.) 

After  June  1991,  additional  requests-for-change  (RFCs)  were  approved,  resulting  in  both 
editorial  modifications  and  additional  VPF  optional  functions.  In  late  1991,  VPF  was  reviewed 
by  both  DMA  and  over  fifty  DOD  organizations  and  offices.  This  review  was  the  source  of 
most  of  the  RFCs  of  1991  and  early  1992.  In  April  1992,  after  all  DOD  comments  had  been 
addressed,  the  Vector  Product  Format  Military  Standard  (MIL-STD-600006)  was  released  by 
DMA  to  the  Defense  Printing  Service  for  distribution  to  all  DOD  agencies  and  the  public.  This 
release  of  VPF  is  known  as  VPF  Version  1.0. 

The  key  aspect  of  the  utility  of  VPF  is  that  VPF  is  the  first  "direct-use"  standard.  Section  2.4.2 
defines  and  discusses  die  direct-use  concept.  Initially,  however,  in  Section  2.4.1,  existing 
exchange  standards  are  discussed  to  allow  comparison  of  the  concepts  of  "exchange"  and 
"direct  use."  Section  2.4.3  describes  the  design  goals  of  VPF  development,  and  Section  2.4.4 
describes  all  the  georelational  characteristics  and  components  of  VPF.  Section  2.4.5  briefly 
lists  other  VPF  characteristics,  and  Section  2.4.6  is  a  summary.  A  complete  description  of 
VPF  is  found  in  the  VPF  standard  (MIL-STD-600006),  which  is  available  from  the  address 
listed  in  Appendix  B. 
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2.4.1  Existing  Exchange  Standards 

During  1991,  the  Spatial  Data  Transfer  Standard  (SDTS)  was  placed  in  the  Federal  Register  by 
USGS  for  final  public  comment  before  its  adoption  as  a  Federal  Information  Processing 
Standard  (FIPS).  Work  on  this  standard  began  in  1982,  by  a  series  of  committees  composed 
of  government,  university,  and  industry  representatives.  Its  fundamental  mission  is  to  develop 
a  standard  for  the  transfer  of  spatial  data — particularly  for  the  transfer  of  data  on  magnetic  tape. 

In  1988,  the  military  mapping  organizations  in  nine  countries  (Belgium,  Canada,  France, 
Germany,  Italy,  Netherlands,  Spain,  United  Kingdom,  and  the  United  States)  formed  a 
standards  committee  called  the  Digital  Geographic  Information  Working  Group  (or  DGIWG), 
which  has  produced  another  transfer  standard  known  as  DIGEST.  The  sponsoring 
organization  in  Canada  is  the  Directorate  of  Geographic  Operations  of  the  Canadian  Directorate 
of  National  Defense.  The  sponsoring  organization  in  the  United  States  is  the  Plans  and 
Requirements  Directorate  of  the  Defense  Mapping  Agency  (DMA).  DIGEST  uses  a  particular, 
hierarchical  feature/attribute  coding  standard  known  as  the  Feature  Attribute  Coding  Catalog 
(FACC). 

According  to  Section  1.0  of  DIGEST  (Edition  1.0,  June  1991),  the  purpose  of  DIGEST  is  to 
"enable  interoperability  and  compatibility  among  national  and  multinational  systems  and  users. 
[DIGEST]  will  also  support  the  increasing  use  of  joint  development  programs.  In  fact,  it  is 
essential  that  geographic  staffs  inducted  in  the  development  of  national  Geographic  Information 
Systems  ensure  that  the  data  structures  and  feature/attribute  coding  schemes  are  compatible 
with  these  standards...[DlGEST]  applies  to  the  topographic,  hydrographic  and  aeronautical 
institutions  of  the  participating  nations.  [DIGEST]  has  been  built  to  support  exchange  of 
digital  Geo  data  between  the  central  agencies  operating  in  the  geo  scientific  field." 

Standards  such  as  SDTS  and  DIGEST  use  the  underlying  model  of  a  tape  transfer— a 
sequential  file  constructed  to  be  read  once  from  beginning  to  end  to  load  a  database  into  the 
target  system.  Both  standards  use  ISO  8211 — a  standard  developed  by  information  exchange 
specialists  to  provide  a  self-describing  exchange.  ISO  8211  has  to  be  read  in  a  strictly 
sequential  order  to  understand  the  content.  The  approaches  of  these  two  standards  are  fine  for 
their  intended  purpose,  cartographic  data  exchange. 

2.4.2  VPF— The  First  Direct-Use  Standard 

VPF  was  developed  to  be  a  direct-use  standard,  not  a  transfer  standard.  The  goal  of  VPF  is  to 
allow  users  to  build  database  products  in  this  standard,  and  then  use  the  products  directly  by 
GIS  software  systems.  VPF  is  designed  for  media  that  can  be  used  directly  and  interactively 
by  software — magnetic  hard  disks  and  optical  compact  discs  with  read-only  memory 
(CD-ROMs).  VPF  must  provide  for  random  access  to  each  individual  record  without  scanning 
a  whole  CD-ROM  or  hard  disk;  hence,  it  must  provide  most  of  the  services  of  an  internal 
database  manager  of  an  integrated  GIS  software  package,  including  supplying  descriptive 
schema  definition  tables. 

Like  SDTS  and  DIGEST,  VPF  is  "self-describing,"  meaning  that  it  has  schema  definition 
tables  built  into  the  data  content;  but  unlike  SDTS  and  DIGEST,  these  schema  definition  tables 
can  be  accessed  whenever  needed  by  software,  instead  of  in  a  strictly  sequential  order. 
Therefore,  using  these  schema  tables,  software  can  determine  the  database  design  of  the  actual 
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data.  The  schema  tables  (also  known  as  metadata — or  data  about  data)  can  also  be  directly 
displayed  to  the  user  to  support  on-line  data  dictionary  functions,  legend  functions,  data  quality 
descriptions,  geographic  reference  (or  "inset")  maps,  or  the  presentation  of  other  information 
that  is  normally  found  on  the  borders  of  printed  maps. 

Another  requirement  for  a  user-oriented  data  standard  is  that  it  be  able  to  represent  a  wide 
variety  of  databases.  VPF  is  based  on  a  single,  general  model  that  supports  a  wide  variety  of 
data,  including  integrated  and  layered  products  and  complex  and  simple  product  schemas'  In 
contrast,  interchange  formats  must  support  multiple  data  models,  providing  for  the  interchange 
between  them.  Thus,  interchange  formats  are  not  directly  readable  by  any  single  application. 
Since  VPF  relies  upon  a  single  data  model,  it  permits  the  development  of  generic  software  and 
allows  the  direct  use  of  geodata. 

2.4.3  VPF  Design  Goals 

In  addition  to  the  direct  use  design  goal  described  above,  three  other  goals  are  accomplished  by 
VPF: 


■  VPF  supports  GIS  applications 

■  VPF  is  compatible  with  DIGEST 

■  VPF  will  directly  support  data  quality  information 

These  goals  are  reviewed  in  detail  below. 

2.4.3.1  VPF  Support  of  GIS  Applications 

A  geographic  data  model  consists  of  three  parts:  objects,  operators,  and  rules.  Even  though 
VPF  is  a  database  format  describing  only  objects,  the  designers  of  VPF  understood  and 
accounted  for  issues  associated  with  the  future  development  of  operators  and  rules  needed  for  a 
fully  functional  GIS.  VPF  is  based  upon  the  same  georelational  model  as  many  commercial 
GIS  formats  and  systems,  including  ARC/INFO,  ODYSSEY,  DLG,  TIGER,  SYSTEM  9,  and 
others.  The  georelational  model  provides  a  foundation  for  a  GIS,  allowing  the  definition  of 
operators  that  act  upon  spatial  location  information  and  thematic  information,  across  geometry, 
topology,  and  attribute  tables.  In  addition,  VPF  goes  beyond  current  commercial  GIS  formats 
to  include  specific  definitions  for  formal  data  quality  modeling,  complex  geographic  features 
composed.of  different  topological  types,  active  and  passive  data  dictionaries,  support  for  both 
tiling  and  the  seamless  assembly  of  tiles,  support  for  cross-tile  topology,  and  support  for 
AN  SI- SPARC  user  view  modeling. 

2.4.3.2  VPF/DIGEST  Compatibility 

VPF  was  developed  at  a  time  when  a  significant  international  interchange  standard  for 
geographic  data  known  as  DIGEST  was  being  formulated.  Although  the  direct  use  objective 
placed  a  different  design  goal  on  VPF,  VPF  was  still  designed  to  be  compatible  with  DIGEST. 
This  compatibility  appears  in  the  terminology  used,  and  accounts  for  most  of  the  system- 
defined  file  suffixes. 
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Beginning  in  June  1991,  VPF  and  DIGEST  became  even  more  closely  linked.  At  that  time, 
DIGEST  incorporated  the  VPF  georelational  model  for  vector  data  into  its  family  of  standards. 
(Within  DIGEST,  VPF  is  known  as  vector  relational  format.)  Thus,  DIGEST  contains  both  an 
exchange  format  and  a  direct-use  format.  VPF  continued  to  undergo  development  during 
1991,  and  a  revised  version  of  VPF  was  incorporated  into  DIGEST  Version  1.1  in  the  fall  of 
1991.  It  is  anticipated  that  the  relationship  of  VPF  as  a  component  of  DIGEST  will  continue 
into  the  future. 

2.4.3.3  VPF  Support  of  Data  Quality  Information 

VPF  allows  for  the  storage  of  data  quality  information  to  permit  the  evaluation  of  the  data  for 
particular  applications.  Although  the  exact  form  of  the  data  quality  information  supplied  for  a 
database  is  set  by  a  product  specification,  VPF  supports  incorporation  of  data  quality 
information  at  each  structural  level  in  the  database  (see  Table  3).  Data  quality  information  may 
be  stored  at  any  VPF  level.  When  it  exists  at  a  given  level,  it  applies  to  all  data  at  or  below  that 
level.  However,  when  data  quality  information  exists  at  multiple  levels,  the  information  stored 
at  lower  levels  always  takes  precedence  over  that  at  the  higher  levels. 

Table  3.  VPF  Data  Quality  Information 


Level 

Location  of  Data  Quality  Attributes 

Location  of  Data  Quality  Coverages 

Database 

In  the  data  quality  table  within  the 
database  directory. 

Within  the  database  directory. 

Library 

In  the  data  quality  table  within  die 
library  directory. 

Within  the  library  directory. 

Coverage 

In  the  data  quality  table  within  the 
coverage  directory. 

"Layer-equivalent"  data  quality 
coverages. 

Feature 

In  the  feature  attribute  table. 

Not  applicable. 

Primitive 

In  the  primitive  table. 

Not  applicable. 

A  VPF  database  may  contain  seven  types  of  data  quality  information:  source,  positional 
accuracy,  attribute  accuracy,  date  status,  logical  consistency,  feature  completeness,  and 
attribute  completeness.  The  extent  of  the  data  quality  information  contained  in  a  product  and 
the  types  of  data  quality  to  be  included  are  determined  by  the  product  specification. 

As  shown  by  Table  3,  data  quality  information  can  be  represented  as  an  attribute  or  as  a 
coverage.  In  the  case  of  attributes,  data  quality  information  may  be  added  to  an  existing  VPF 
table,  stored  in  a  separate  table,  or  stored  in  a  special  data  quality  table. 
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2.4.4  The  VPF  Georelational  Model 

VPF  uses  a  combination  of  the  relational  and  planar  topological  data  models  to  provide  a 
powerful  hybrid  for  a  spatial  database  within  a  GIS.  The  VPF  georelational  model  provides 
the  data  structures  for  a  spatial  database,  whereas  a  GIS  provides  the  rules  and  operators  that 
manipulate  topology,  geometry,  and  relational  objects  in  the  form  of  tables.  Whenever  an 
operation  requires  thematic  information,  the  use  of  relational  and  topologic  table  operations  are 
used  to  supply  the  result.  If  the  operation  is  spatially  related,  the  use  of  geometry  and  topology 
together  will  be  used.  This  triad  of  principles  (geometry,  topology,  and  relational  tables) 
provides  a  robust  database  architecture  for  VPF.  A  geometric  model  would  only  use  geometry 
and  relational  tables  together.  (Note:  Additional  background  regarding  the  three  models  used 
by  VPF  is  provided  in  Appendix  A  of  the  VPF  military  standard.) 

2.4.4.1  VPF  Thematic  Objects 

VPF  thematic  data  objects  consist  of  information  that  is  a  combination  of  structural  data 
organization  (directories)  and  information  stored  in  tables,  such  as  metadata  and  feature 
attributes. 

VPF  organizes  its  geographic  objects  by  means  of  database,  library,  and  coverage  directories. 
The  database  directory  consists  of  a  set  of  libraries,  in  addition  to  any  tables  that  supply 
information  to  the  entire  database.  A  library  directory  references  the  extent  of  the  geographic 
information  contained  within  it  All  other  VPF  structures  are  confined  to  libraries.  A  coverage 
directory  defines  the  topologic  and  thematic  relationships  of  features.  The  coverage  can  be 
thought  of  as  a  map  sheet  in  its  digital  form.  All  the  geographic  feature  information  of  a 
coverage  is  contained  within  it 

Within  VPF  tables,  thematic  information  is  stored  as  attributes  and  metadata.  Attributes  are 
used  to  express  more  information  concerning  the  geometric  and  topologic  primitives  of  the 
database.  For  instance,  a  river  feature  may  carry  a  variety  of  attributes  that  help  to  define  the 
geographic  object,  describing  river  width,  depth,  flow  rate,  and  flood  level.  Metada.i  provides 
general  information  about  the  geographic  data  within  a  database,  library,  or  coverage.  For 
example,  a  geographic  reference  table  is  used  to  determine  the  spatial  extent  of  a  library. 
Schema  tables  are  another  form  of  metadata  and  are  used  to  navigate  through  these  directory 
structures,  defining  the  relationships  within  them.  These  schema  tables  are  required  to  provide 
the  information  necessary  to  access  the  database  without  associated  software  having 
predetermined  knowledge  of  the  data  structure  organization. 

2.4.4.2  VPF  Topologic  Objects 

VPF  topologic  objects  define  feature  relationships.  A  feature  is  composed  of  geometric  and 
thematic  tables.  There  are  three  feature  types  in  VPF:  point,  line,  and  area  tables,  which 
contain  the  topological  constructs  of,  respectively,  the  node,  edge,  and  face  primitives.  Feature 
tables  also  usually  contain  attribute  information,  but  they  are  mainly  used  to  define  these 
topologic  constructs. 

For  instance,  a  landmark  (oil  well  or  television  tower)  can  be  defined  as  a  point  feature,  which 
relates  to  the  node  primitive  table.  The  landmark's  topologic  information,  in  addition  to 
thematic  information  (such  as  height,  material,  and  construction),  contains  any  relations  to  a 
surrounding  area  feature  or  connecting  line  features. 
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An  example  of  a  linear  feature  is  a  road.  Each  road  feature  maintains  a  geometric  relation  with 
an  edge  primitive.  The  road  will  have  a  start  node  and  an  end  node,  which  define  a  geometric 
direction.  Each  road  feature  is  part  of  a  network;  that  is,  information  is  contained  within  the 
database  as  to  which  roads  intersect  any  other  given  road  at  each  node.  Any  given  road  will 
always  maintain  a  left*  and  right-neighbor  relationship  with  an  area  feature,  if  one  exists. 

A  lake  is  an  example  of  an  area  feature.  In  addition  to  being  related  to  attributes,  a  lake  is 
related  to  face  primitives.  A  lake  is  topologically  related  to  any  other  feature  that  is  found 
within  it  (islands)  or  that  touches  its  borders  (rivers,  springs,  or  streams). 

2.4.4.3  VPF  Geometric  Objects 

In  VPF,  features  are  created  from  four  basic  geometric  object  primitives:  nodes,  edges,  faces, 
and  text  Node,  edge,  and  face  primitives  are  used  to  represent,  or  model  the  geometric 
component  of,  real-world  geographic  phenomena.  Nodes  are  zero-dimensional  primitives  used 
to  represent  the  geometric  component  of  singularly  discrete  geographic  phenomena,  or  to  link 
edges  together.  Edges  are  one-dimensional  primitives  used  to  represent  the  geometric 
components  of  linear  geographic  phenomena.  Faces  are  two-dimensional  primitives 
representing  areas'  enclosed  edges  and  are  used  to  model  the  geometric  components  of  area 
features.  The  text  primitive  is  a  cartographic  primitive  rather  than  a  geographic  primitive;  it 
does  not  represent  anything  in  the  real  world  but  allows  the  placement  of  textual  information  to 
be  stored  in  the  database  without  being  tied  to  any  particular  feature.  The  text  primitive  allows 
identification  of  regions  without  specific  boundaries  such  as  the  Rocky  Mountains  or  the  North 
Pacific  Ocean. 

2.4.5  Additional  VPF  Characteristics 

VPF  is  a  neutral,  machine-independent  format  design  that  must  be  combined  with  a  product 
specification  to  develop  a  given  product.  VPF  does  not  contain  product-specific  information 
such  as  particular  feature  coding  schemes  or  special  relationships  between  features.  VPF 
allows  such  information  to  be  encoded  and  described,  but  this  information  is  not  part  of  VPF 
itself.  Neither  does  VPF  define  the  geographic  entities  and  objects  to  be  represented.  Instead, 
these  product-specific  design  details  are  carried  in  the  product  specification. 

VPF  provides  logically  continuous  topological  relationships,  even  when  the  database  is 
physically  partitioned  into  tiles.  VPF  is  able  to  manage  data  that  cross  the  tile  boundaries 
through  a  mechanism  called  "winged-edge"  topology,  which  implants  information  about 
features  on  the  left  (or  right  or  top  or  bottom)  of  a  tile  boundary  into  each  feature  that  touches 
the  right  (or  left  or  bottom  or  top)  side  of  the  boundary. 

The  VPF  is  designed  to  support  varying  levels  of  topology  and  varying  degrees  of  integration. 
The  georelational  approach  allows  data  to  be  separated  into  layers.  When  applications  do  not 
require  querying  the  relationship  among  data  types,  data  can  be  stewed  and  accessed  efficiently 
in  separate  layers.  When  such  queries  are  required,  the  layers — carrying  full  topological 
relationships — can  be  integrated. 

For  a  complete  description  of  VPF,  refer  to  the  VPF  military  standard,  which  is  available 
through  the  address  provided  in  Appendix  B. 
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2.4.6  Summary 

VPF  is  a  standard  format,  structure,  and  organization  for  large  geographic  databases.  VPF  is 
based  on  a  georelational  data  model  and  supports  direct-use  applications.  VPF  is  designed  to 
be  compatible  with  a  wide  variety  of  applications  and  products.  VPF  allows  application 
software  to  read  data  directly  from  computer-readable  media  without  prior  conversion  to  an 
intermediate  form.  VPF  uses  tables  and  indexes  that  permit  direct  access  by  spatial  location 
and  thematic  content  and  is  designed  to  be  used  with  any  digital  geographic  data  in  vector 
format  that  can  be  represented  using  nodes,  edges,  and  faces.  VPF  defines  the  format  of  data 
objects,  and  the  georelational  data  model  provides  a  data  organization  within  which  software 
can  manipulate  die  VPF  data  objects.  A  product  specification  corresponding  to  a  specific 
database  product  determines  the  precise  contents  of  feature  tables  and  their  relationships  in  the 
database.  In  this  context,  each  separate  product  or  application  is  defined  by  a  product 
specification  and  implemented  by  using  VPF  structures. 


2.5  VPFVIEW  Software  Development 

2.5.1  Introduction 

In  the  past,  the  Defense  Mapping  Agency  (DMA)  has  produced  a  variety  of  digital  prototype 
and  production  products.  Most  of  these  products  did  not  provide  the  prospective  user  with  an 
effective  way  to  review  the  data  set  prior  to  delivery;  the  data  sets  were  usually  distributed 
either  with  no  software  or  with  very  limited  software.  The  user  had  to  base  an  evaluation  of 
the  usefulness  of  the  data  set  on  the  documentation  provided  or  expend  the  effort  necessary  to 
write  access  routines.  With  the  creation  of  large  database  products  like  the  DCW,  the  need  for 
effective  review  tools  became  apparent  What  was  needed  was  a  software  system  that  would 
present  the  data  set  and  demonstrate  some  of  its  basic  uses.  Data  set  users  provided  with  a 
system  of  this  type  would  have  both  clear,  operating  examples  of  data  access  and  a  model  for 
the  development  of  user  software  applications. 

Because  DMA  recognized  the  value  of  demonstration  software,  one  of  the  objectives  of  the 
DCW  project  was  to  develop  an  effective  tool  for  the  demonstration  and  review  of  the  DCW 
data  set  Another  was  to  provide  a  toolbox  of  program  tools  with  the  DCW  that  would  allow 
the  user  to  develop  additional  applications  based  upon  the  DCW  product.  These  objectives 
were  met  with  the  development  of  the  VPFVIEW  software  product  that  was  distributed  with 
the  DCW  database. 

Starting  from  Prototype  4,  significant  progress  was  made  in  developing  a  generic  application 
software  product  called  VPFVIEW  to  allow  display  of  all  data  structured  in  accordance  with 
VPF.  The  refinement  of  VPFVIEW  continued  until  recently. 

2.5.2  Overview  of  VPFVIEW  Chronological  Development 

The  DCW  application  software  (which  was  later  named  VPFVIEW)  was  designed  through 
prototyping.  The  design  approach  was  to  build  a  functional,  useful  prototype,  and  then  modify 
the  prototype  through  user  feedback.  Software  prototypes,  delivery  dates,  and  the  design 
focus  of  each  prototype  development  effort  are  listed  in  Table  4. 
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Table  4.  VPFVIEW  Software  Prototypes 


Prototype 

Delivery  Date 

Design  Emphasis 

DCW  Application  Software 

Prototype  2  (DOS) 

April  1990 

Conceptual  design  of  the  user  interface 

DCW  Application  Software 

Prototype  3  (DOS) 

Aug,  1990 

Complete  user  interface  and  preliminary 
program  functions 

DCW  Application  Software 

Prototype  4  (DOS) 

Dec.  1990 

Complete  software  for  use  with  (only) 
DCW 

VPFVIEW  Prototype  1  (DOS) 

May  1991 

Conceptual  design  of  View  and  Theme 
functions  to  allow  use  with  all  VPF 
products 

VPFVIEW  Prototype  2  (DOS) 

Oct  1991 

Preliminary  design  of  all  generic- 
VPFVIEW  functions  and  incorporation 
of  unit  and  integration  testing  error  fixes 

VPFVIEW  Product  (DOS) 

March  1992 

Incorporation  of  functional  testing  error 
fixes.  Distribution  version  for  the 

DCW  database 

VPFVIEW-UNIX  port  version 

June  1992 

Porting  of  the  DOS  version  to  UNIX 

VPFVIEW-UNIX  alpha  version 

Aug.  1992 

Incorporation  of  join-table  and  complex 
feature  handling  based  on  the 

TESTDTLM  database 

VPFVIEW-UNIX  beta  version 
(planned) 

OcL  1992 

Incorporation  of  multilibrary  and 
multidatabase  display  capabilities 

VPFVIEW-UNIX  final  version 
(planned) 

Dec.  1992 

Incorporation  of  unit,  integration,  and 
functional  testing  error  fixes 

Table  4  shows  that  from  1990  to  1992  there  were  three  distinct  development  phases  for  the 
VPFVIEW  software.  Initially,  in  accordance  with  the  original  DCW  contract,  the  DCW 
applications  software  was  designed  and  developed  purely  for  use  with  the  DCW  database. 

This  development  phase  continued  throughout  1990,  as  shown  in  Table  4. 

However,  early  in  1991,  DMA  recognized  the  value  of  expanding  the  DCW  applications 
software  into  a  generic  software  product  that  would  accomplish  functions  similar  to  those  of 
the  original  software  (namely,  database  demonstration),  but  would  also  be  able  to  display  any 
database  developed  in  accordance  with  the  VPF  standard.  Thus,  the  software  development 
effort  set  out  on  a  new  tack  with  new  functional  requirements.  The  result  of  this  redirection 
was  ultimately  the  VPFVIEW  product,  which  was  distributed  with  the  first  edition  of  the  DCW 
database  in  the  summer  of  1992.  The  VPFVIEW-DOS  development  and  testing  thus 
represents  the  second  phase  of  software  development  in  the  DCW  project  (Please  refer  again 
to  Table  4.) 

Finally,  having  proven  that  a  VPF-generic  software  product  could  be  implemented  on  a  small 
DOS  hardware  platform  through  the  release  of  VPFVIEW-DOS,  DMA  again  expanded  the 
original  scope  and  functional  requirements  of  the  software  to  accomplish  other  user 
requirements  unrelated  to  the  DOS  platform.  These  requirements  will  be  met  in  the 
VPFVIEW-UNIX  product,  which  is  still  under  development.  They  include  expanding 
VPFVIEW-DOS  to  simultaneously  display  multiple  VPF  libraries  contained  within  one  or 
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more  VPF  databases.  The  VPFVIEW-UNIX  development  and  testing  is  occurring  during  the 
latter  three-quarters  of  1992,  as  shown  in  Table  4. 

Most  of  the  remainder  of  Section  2.5  will  discuss  each  of  these  three  phases  in  turn. 

Sections  2.5.4  and  2.5.5  discuss  the  DCW  applications  software  design  and  development; 
Sections  2.5.6  and  2.5.7  describe  VPFVIEW-DOS  design,  development,  and  testing;  and 
Section  2.5.8  relates  the  VPFVDEW-UNIX  design  objectives,  and  refers  to  the  development 
and  upcoming  testing  efforts.  First,  however,  Section  2.5.3  will  list  the  hard  ware/software 
environments  upon  which  the  two  software  products  were  implemented  and  will  operate. 

2.5.3  VPFVIEW  Hardware  and  Software  Environments 

2.5.3.1  VPFVIEW-DOS  (and  DCW  Applications  Software)  Hardware  and 
Software  Environment 

The  recommended  hardware  environment  for  VPFVIEW-DOS  is: 

■  Computer  with  an  80386  processor  and  an  80387  math  coprocessor 

■  Video  Graphics  Array  (VGA)  and  compatible  monitor 

■  Mouse  driver 

■  High-density  floppy  drive  (5- 1/4  inch  or  3-1/2  inch) 

■  30  MB  hard  drive  with  at  least  20  percent  free  disk  space 

■  2  to  4  MB  Random  Access  Memory  (RAM) 

■  MS-DOS  Version  3.1  or  higher  (except  Version  4.0,  which  is  not  recommended 
because  of  its  additional  memoiy  requirements) 

■  CD-ROM  drive  (ISO  9660  compatible)  (optional) 

■  Microsoft  MS-DOS  CD-ROM  Extensions  Version  2.0  or  higher  (optional) 

■  Printer  capable  of  reading  PostScript  formatted  files  (option;)) 

■  Line  printer  (optional) 

VPFVIEW-DOS  will  also  function  in  the  following  environment: 

■  Computer  with  an  80286  processor  and  an  80287  math  coprocessor 

■  1  MB  RAM 

■  Enhanced  Graphics  Adapter  (EGA)  and  compatible  monitor 

■  Arrow  key  interface 
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2.S.3.2  VPFVIEW-UNIX  Hardware  and  Software  Environment 

Although  VPFVIEW-UNIX  will  operate  on  systems  with  less  capability,  the  recommended 
hardware  and  software  environment  for  VPFVIEW-UNIX  is: 

■  Sun  SPARCstation  2 

■  32  MB  of  internal  memory 

■  8-bit  Sun  Graphics  Accelerator  (GX)  board 

■  600  MB  hard  disk 

■  CD-ROM  Small  Computer  Standard  Interface  (SCSI)  device 

■  PostScript  output  device 

■  SunOS  4.1  or  higher 

■  OPEN  LOOK  Version  3.0  windowing  environment 

■  Sun  XView  libraries 

■  Sun  X  Window  System 

2.5.4  DCW  Applications  Software  Design  Objectives 

The  primary  DCW  applications  software  design  objectives  were  to  make  the  software  both  user 
and  programmer  friendly,  because  the  software  would  be  released  in  the  public  domain. 
Software  design  was  constrained  in  speed  and  memory  because  of  the  CD-ROM  and  the  DOS 
hardware/software  environment  The  software  design  requirements  were  that  it  should  be  used 
to  access  the  DCW  database  implemented  with  VPF,  display  the  selected  features,  and  create 
reports.  Therefore,  the  software  focuses  mainly  on  displaying  the  database,  and  its  analytical 
capability  is  very  limited.  The  software  enables  the  user  to  select  data  for  display  by 
geographic  region  as  well  as  by  type,  and  it  also  enables  the  user  to  display  and  evaluate  die 
database  directly  from  CD-ROM,  hard  drive,  or  diskette  without  loading  cm-  converting  the 
data  Once  a  display  has  been  generated,  the  user  can  save  either  the  data  request  itself  or  the 
results  of  the  request  on  the  hard  drive.  If  the  appropriate  hardware  has  been  connected, 
displays  and  text  reports  can  be  printed. 

2.5.5  DCW  Applications  Software  Development 

As  described  in  Section  2.2,  the  DCW  applications  software  was  continually  modified  during 
the  four  DCW  prototypes  in  1990.  The  design-by-prototyping  approach  meant  that  functions 
were  gradually  implemented  and  refined  throughout  the  prototype  period  based  on  the  design 
and  comments  obtained  from  the  DCW  participants. 

Starting  from  Prototype  3,  VPF  data  structure  was  implemented  and  new  user-oriented 
functions  were  added  to  the  software.  A  Browse  map  was  added  to  Prototype  4  that  allowed 
the  user  to  zoom  and  pan  to  determine  an  area  of  interest.  Another  major  addition  to 
Prototype  4  was  the  Spatial  Query  function,  which  allowed  the  user  to  point  at  a  location  on 
the  screen  and  see  all  the  attribute  information  for  features  that  fell  at  that  location.  The 
Prototype  4  version  of  the  software  in  December  1990  was  the  last  release  of  the  DCW 
applications  software.  After  that  point,  development  focused  on  VPFVIEW-DOS,  as 
described  in  Section  2.5.2.  The  remainder  of  this  section  (2.5.5)  will  describe  functions  that 
were  developed  within  the  DCW  applications  software,  and  also  carried  forward  into  the 
VPFVIEW-DOS  and  VPFVIEW-UNIX  developments. 
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The  DCW  applications  software  was  designed  to  utilize  user-oriented  menus  which  allow  the 
user  to  easily  understand  and  operate  the  software.  The  menu  functions  are  activated  by 
selection  with  a  mouse.  The  cursor  is  placed  on  the  desired  function,  a  mouse  button  is 
pressed,  and  the  function  is  initiated  There  are  as  many  as  four  levels  of  menus;  there  is  a 
main  menu,  and  submenus  can  be  accessed  from  each  of  them.  The  main  menu  is  composed 
of  the  System  function,  VPF  Content  function.  Feature  Selection  function,  Graphics  function. 
Text  Report  function,  and  Archive  function.  The  menus  are  arranged  from  left  to  right  in  the 
approximate  sequence  in  which  they  would  be  used  in  a  typical  session.  The  main  menu 
provided  the  framework  upon  which  lower-level  functions  and  enhancements  were  later  added 
and  implemented. 

Options  on  the  System  menu  allow  the  user  to  perform  DOS  operations  on  the  files  and 
directories  on  PC  without  leaving  the  application  software  or  the  DCW  database.  This  menu 
was  implemented  to  provide  access  to  other  files  on  the  PC  while  the  user  is  engaged  in 
applications  sessions  with  the  DCW  database.  The  VPF  Contents  menu  options  enable  the 
user  to  examine  the  contents  of  die  DCW  database  and  manipulate  the  organization  of  the 
information  within  the  database. 

The  Feature  Selection  menu,  which  comprises  both  a  main  menu  and  a  set  of  submenus, 
enables  the  user  to  select  the  coverages  and  the  associated  themes  that  the  user  wants  to  include 
in  the  screen  display  or  other  reporting  options.  The  Graphics  menu  enables  the  user  to 
enhance  the  visual  characteristics  of  the  screen  display  and  create  files  for  hard  copy  output. 

The  Text  Report  menu  enables  the  user  to  generate  simple  text  reports  which  provide 
information  on  features  associated  with  coverages  and  themes  the  user  selects.  The  user  can 
display  an  area  content  summary  to  a  feature  location  list  on  the  screen,  send  it  to  a  printer,  or 
save  it  to  disk. 

Through  the  options  on  the  Archive  menu,  the  user  can  save  and  restore  feature  selection  sets, 
symbology,  screen  displays,  and  the  data  specific  to  the  user's  current  study  area.  Three  lower 
levels  of  submenus  under  the  main  menu  were  designed  to  provide  the  user  with  further 
options  and  more  choices  in  system  operation,  data  contents  accessing,  feature  selection, 
viewing,  and  reporting. 

The  detailed  descriptions  for  menu  operations  can  be  found  in  the  VPFVIEW  Users  Manual  for 
the  Digital  Chart  of  the  World,  which  is  distributed  with  the  DCW  database  product. 

2.5.6  VPFVIEW-DOS  Design 

As  described  in  Section  2.5.2,  early  in  1991  DMA  directed  ESRI  to  expand  the  functions  of  the 
DCW  applications  software  to  allow  automatic  and  direct  demonstration  of  any  database  that 
was  formatted  in  accordance  with  the  VPF  military  standard  It  was  possible  to  do  this  because 
data  formatted  in  accordance  with  VPF  include  database  schema  tables  that  the  software  would 
read  which  define  the  format  for  the  remaining  data  in  a  particular  VPF  database.  At  that  point, 
the  software  was  renamed  as  "VPFVIEW"  to  reflect  both  its  VPF-generic  nature  and  the  fact 
that  a  new  concept  known  as  user  "views"  was  added  to  the  software  concept  and  design. 

"Views"  are  the  mechanism  by  which  VPFVIEW  displays  the  results  of  thematic  queries. 

Every  view  contains  symbols  for  all  coverages  in  a  VPF  library.  VPF  coverages  are  made  up 
of  feature  classes  (areas,  lines,  points,  and  text;  see  Section  2.4).  Themes  are  the  core  of  the 
view.  Several  themes  may  be  created  from  each  feature  class  in  a  coverage.  For  example, 
different  themes  may  be  created  for  different  types  of  roads  (multiple  lane,  single  lane,  tracks 
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and  trails,  and  connectors),  even  though  all  roads  are  in  the  same  feature  class  (lines)  and  also 
in  the  same  coverage  (roads).  A  view  is  the  set  of  all  themes  that  has  been  created  for  a 
coverage. 

In  VPFVIEW-DOS ,  a  View  submenu  was  implemented  under  the  VPF  Contents  menu.  It 
contains  a  series  of  lower  level  submenus,  including  select  view,  create  view,  delete  view, 
copy  view,  rename  view,  create  theme,  delete  theme,  and  modify  theme.  The  create  theme  and 
modify  theme  submenus  allow  users  to  build  symbology  for  their  VPFVIEW  displays. 

2.5.7  VPFVIEW-DOS  Development  and  Testing 

VPFVIEW-DOS  development  occurred  during  the  period  from  March  1991  to  March  1992. 

As  indicated  in  Section  2.5.2,  three  releases  of  VPFVIEW-DOS  were  delivered  to  DMA.  The 
first  release  in  May  1991  initially  implemented  the  "View"  and  "Theme"  functions.  In  October 

1991,  all  VPFVIEW-DOS  functions  were  implemented,  and  some  of  the  errors  identified 
through  unit  testing  and  integration  testing  of  VPFVIEW  were  repaired.  The  final  version  was 
submined  in  March  1992  and  included  all  repairs  for  all  errors  identified  in  the  unit,  integration, 
and  functional  testing  processes. 

Software  testing  was  conducted  on  VPFVIEW-DOS  over  a  period  from  August  1991  until 
March  1992.  Software  testing  verified  error-free  linkage  and  operation  of  all  VPFVIEW-DOS 
units.  Unit  testing  was  performed  by  ESRI's  software  quality  assurance  organization,  which 
was  independent  of  the  ESRI  software  development  team.  Integration  testing  was  performed 
by  Loral  Defense  Systems — Akron,  Ohio.  Functional  testing  was  conducted  by  both 
organizations  and  witnessed  by  DMA  software  testing  personnel. 

Unit  testing  was  conducted  for  all  units  of  the  VPFVIEW-DOS  software.  Unit  testing  is  the 
line-by-line  testing  of  a  unit  isolated  from  all  other  units.  Dummy  routines  were  generally  used 
for  some  or  all  of  the  units  that  were  subordinate  to  the  unit  being  tested.  Although  no  project 
requirement  existed  for  the  development  of  VPFVIEW  in  ANSI  C,  most  VPFVIEW-DOS 
modules  were  successfully  verified  on  an  ANSI  C  compiler. 

Integration  testing  involves  testing  a  unit  with  its  subordinate  units  and  peers  intact.  Integration 
tests  were  performed  on  units  from  one  or  more  modules,  but  did  not  generally  include  all  the 
units  from  any  one  module.  Integration  testing  was  conducted  for  all  units  comprising  the 
VPFVIEW-DOS  software.  An  integration  test  report  was  provided  to  DMA  in  the  spring  of 

1992. 

Functional  testing  is  the  testing  of  each  and  every  user-accessible  function  of  the  application 
program.  Functional  testing  was  performed  on  every  external  program  function.  The  final 
functional  test  represented  a  single  acceptance  test  of  VPFVIEW-DOS.  Functional  testing  was 
recorded  via  checklists.  A  functional  test  report  was  provided  to  DMA  in  the  spring  of  1992. 
These  documents  included  the  software  test  checklists  and  provided  descriptions  of  problems 
encountered  and  solutions  implemented. 

Functional  testing  of  VPFVIEW-DOS  consisted  of  running  the  1,903  tests  described  in  the 
functional  test  plan,  which  was  submitted  and  approved  by  DMA  prior  to  the  functional  testing 
activity.  Testing  was  conducted  over  the  one-week  period  from  March  16  to  March  20, 1992, 
at  ESRI.  The  testing  was  conducted  by  three  two-person  teams  using  three  machines.  Each  of 
the  three  two-person  teams  was  responsible  for  testing  a  different  set  of  the  software  functions 
outlined  in  the  functional  test  plan.  As  testing  proceeded,  each  team  annotated  a  copy  of  the 


September  1992 


2-41 


Chapter  2  -  Phase  I— Design  and  Prototyping 


functional  test  plan,  initialing  those  tests  that  were  completed  successfully.  These  three 
annotated  copies  of  the  functional  test  plan  are  on  file  at  ESR1.  When  the  full  complement  of 
1,903  tests  were  complete,  fifty  software  discrepancy  reports  were  filed,  so  the  software 
performed  successfully  in  97  percent  of  the  tests.  Of  the  fifty  discrepancies,  forty-four  were 
very  minor  and  were  repaired  within  two  days  of  being  identified.  The  remaining  six 
discrepancies,  which  were  minor,  were  repaired  within  two  weeks  of  being  identified. 

2.5.8  VPFVIEW-UNIX  Design  Objectives 

After  the  release  of  VPFVIEW-DOS ,  DMA  again  expanded  the  original  scope  and  functional 
requirements  of  the  VPFVIEW  software  to  accomplish  other  user  requirements  unrelated  to  the 
DOS  platform  These  requirements  will  be  met  in  the  VPFVIEW-UNIX  product 

VPFVIEW-UNIX  design  efforts  are  currently  continuing.  The  VPFVIEW-UNIX  detailed 
design  document  was  recently  delivered  to  DMA,  and  two  prototype  versions  of  the  software 
have  also  been  delivered.  Development  and  testing  will  continue  throughout  1992.  The 
VPFVIEW-UNIX  1 .0  will  be  delivered  in  December  of  1 992. 

VPFVIEW-UNIX  will  contain  virtually  the  same  basic  functions  as  the  DOS  version,  except 
that  it  will  run  on  a  Sun  SPARC  family  workstation  under  the  OPEN  LOOK  Graphical  User 
Interface  (GUI;  see  Section  2.5.3).  Use  of  OPEN  LOOK  will  result  in  a  significantly  different 
user  "look  and  feel,"  since  VPFVIEW-DOS  used  an  application-specific  GUI.  VPFVIEW- 
UNIX  will  display  any  valid  VPF  version  1.0  (or  earlier)  dataset.  The  software  assumes  that 
the  data  conform  to  the  VPF  standard. 

The  primary  extension  of  VPFVIEW-UNIX  (over  VPFVIEW-DOS)  is  that  it  will  allow  data 
from  different  VPF  databases  and  different  VPF  libraries  to  be  displayed  simultaneously. 
Themes  within  a  view  will  be  able  to  reference  different  databases  and  libraries,  as  well  as  data 
from  different  feature  classes.  Because  different  VPF  libraries  can  be  stored  in  different 
coordinate  systems,  VPFVIEW-UNIX  must  be  able  to  conduct  "on-the-fly"  transformations  of 
all  of  the  projections  supported  by  VPF  in  support  of  visual  displays.  Other  operational  and 
user-interface  components  must  change  substantially  to  incorporate  this  difference  in  displaying 
data  sources.  VPFVIEW  functions  that  will  undergo  expansion  or  modification  include  theme 
creation,  feature  selection  list  specification,  text  reporting,  the  save  selected  data  function,  map 
display,  view  manipulation,  Libref  coverage  display,  and  hard-copy  creation. 

Significant  improvements  to  symbology  will  also  be  achieved  in  the  VPFVIEW-UNIX 
version.  The  higher  display  resolution  of  the  platform  will  be  an  obvious  improvement  over 
VPFVIEW-DOS.  Colors  will  be  extended  to  be  able  to  access  a  full  range  of  16-bit  Red, 
Green,  Blue  (RGB)  color  values.  Polygon  fill  styles  will  incorporate  custom  fill  patterns,  and 
the  user  will  be  able  to  specify  different  line  styles  for  outlines.  Several  new  line  symbols  will 
be  added  to  the  set  of  supported  line  styles.  Approximately  twenty  additional  Mark  90  line 
symbols  will  be  supported.  Marker  symbols  will  be  extended  to  include  a  "hot  spot"  that  will 
be  centered  on  the  geographic  location  instead  of  the  current  default  center  of  the  symbol.  It 
will  be  possible  to  display  text  in  a  variety  of  faces,  styles,  and  sizes,  using  any  of  the  fonts 
supported  by  the  X  Window  System.  Marker  symbols  and  text  will  be  seal ed  down  when 
zooming  out  to  reduce  display  clutter.  Each  view  will  be  able  to  specify  a  custom  symbology 
set  location,  upon  creation. 
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3.1  Introduction 

DCW  database  production  was  one  of  the  main  tasks  for  the  DCW  project,  and  as  expected  it 
claimed  the  largest  portion  of  the  project's  resources.  The  production  effort  included 
developing  both  the  GIS  database  and  standard  procedures  for  GIS  database  production.  The 
production  procedures  were  developed  during  the  first  year  of  the  project  as  a  part  of  the 
activities  of  the  prototyping  and  design  phase.  Prototypes  were  developed  during  this  period  to 
explore  the  methodologies  and  standard  procedures  that  were  later  implemented  in  production. 
The  second  year  of  the  project  focused  on  full-scale  production.  Full-scale  production  started 
after  Prototype  4  in  September  of  1990  and  continued  until  April  1992.  A  set  of  SOPs  was 
developed  as  a  technical  guide  for  production.  The  SOPs  were  modified  and  improved 
throughout  the  duration  of  the  project 

Source  data  were  drawn  from  270  ONCs  and  six  JNCs.  Because  of  the  number  of  charts  and 
the  amount  of  data  on  each,  a  production  plan  encompassing  production  procedures  and 
logistics,  facilities,  staffing,  hardware,  software,  and  quality  control  was  created  and 
implemented. 


3.2  Production  Management 

The  production  of  the  DCW  database  was  exceptionally  labor  intensive.  Effective  management 
practices  were  necessary  to  effectively  control  DCW  production. 

3.2.1  Production  Staffing 

Production  staffing  levels  were  analyzed  periodically  and  adjusted  to  meet  the  schedule  during 
production.  Staffing  was  augmented  as  production  warranted;  about  fifty  personnel  worked 
full  time  on  production  during  the  production  peak.  Two  production  shifts  were  implemented 
to  permit  interactive  production  equipment  to  be  fully  utilized.  In  addition,  production  batch 
processing  was  typically  executed  during  the  third  shift. 

3.2.2  Monitoring  Program  Status 

To  assist  project  management  in  monitoring  the  status  of  database  production,  a  Spatial  Project 
Tracking  System  (SPTS)  was  implemented.  SPTS  is  a  tool  that  assists  ESRI  project 
management  in  determining  completion  rates  for  in-house  production.  It  also  is  an  accepted 
and  approved  component  of  ESRI's  Management  Control  System,  a  system  for  tracking  and 
reporting  cost  and  schedule  performance  (Cost/Schedule  Status  Reports).  SPTS  can  produce 
reports  or  maps  describing  a  project's  progress  (percentage  of  completion)  at  any  level  of 
project  organization,  including:  (1)  overall  project;  (2)  mapping  automation  module;  (3)  task; 
and  (4)  subtask.  SPTS  was  utilized  in  the  DCW  project  to  monitor  all  aspects  of  the  database 
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production  process  from  map  preparation  through  to  the  VPF  data  conversion  process.  Other 
management  tracking  tools  such  as  dependency  charting  programs  and  DCW  production  floor 
tracking  charts  were  also  used  to  support  production  management. 


3.3  Production  Environment 

Before  full-scale  production  began,  the  production  environment  was  prepared  by  acquiring 
necessary  hardware  and  software,  establishing  naming  conventions,  developing  the  data 
dictionary,  establishing  production  organization  and  methodology,  and  developing  standard 
operating  procedures. 

Hardware  and  software  requirements  were  carefully  evaluated.  The  hardware  available  was 
assessed  against  the  production  schedule  throughout  the  project  Hardware  that  incorporated 
the  latest  technology  was  acquired  as  necessary  to  ensure  efficient  data  processing  and 
configured  to  permit  communication  through  the  local  area  network.  The  latest  version  of 
ARC/ENFO  (5.0.1)  available  at  production  start-up  was  utilized  extensively  in  the  production 
process. 

A  variety  of  computer  hardware  was  used  for  the  project  The  scanner  used  for  the  DCW 
database  was  a  full-size  optical  scanner  with  a  maximum  resolution  of  1,000  DPI.  The  DPI  of 
the  scanner  is  variable;  most  of  the  scanning  of  the  DCW  database  was  done  at  400  to  500  DPI. 
The  scanner  is  configured  to  a  computer  with  an  80386  processor,  which  was  used  to  store  the 
digital  raster  file  from  the  scanner.  A  commercial  software  package  was  used  to  vectorize  the 
scanned  raster  data  and  to  convert  the  vector  data  into  the  Data  Exchange  Format  (DXF).  The 
database  development  hardware  consisted  of  a  file  server,  nineteen  workstations,  three  tape 
drives  for  data  backup,  ten  digitizing  boards,  one  electrostatic  plotter,  and  two  eight-color  pen 
plotters.  The  hardware  was  configured  into  a  local  area  network,  allowing  data  to  flow  from 
the  scanning/digitizing  processors  to  each  workstation.  The  hardware  and  associated  local  area 
network  configuration  were  specifically  assigned  to  the  DCW  project  and  were  independent  of 
all  other  hardware  within  ESRI.  This  hardware  configuration  ensured  the  effective  use  of 
equipment  and  allowed  efficient  data  flow  and  processing. 


3.4  Production  Sequence 

Seven  production  sets  and  a  production  sequence  were  identified  for  the  DCW  project  The 
production  sets  were  organized  on  the  basis  of  geographic  area,  and  the  sequence  of  the 
production  sets  was  arranged  according  to  DMA's  preference  for  data  availability.  The  sets 
and  sequence  were  as  follows: 

■  Set  1:  Europe 

■  Set  2:  Northern  Asia 

■  Set  3:  South  America 

■  Set  4:  Southern  Asia 

■  Set  5:  Australia 

■  Set  6:  North  America 

■  Set  7:  Africa 
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3.5  Data  Dictionary 

To  guide  database  automation,  a  data  dictionary  was  created  that  reflected  the  DCW  database 
design.  Because  of  the  introduction  of  new  features  in  some  regions  that  were  not  originally 
known  to  exist,  the  data  dictionary  was  refined  six  times  during  the  early  phase  of  the 
production.  Version  6  was  finalized  in  April  1991.  During  the  database  automation  process, 
every  member  of  the  production  staff  kept  a  copy  of  the  data  dictionary  on  hand  for  reference. 

The  DCW  product  utilized  a  feature  coding  system  based  on  the  symbology  guide  for  the  ONC 
charts.  Neither  the  FACS  coding  system  (from  the  Digital  Production  System,  or  DPS)  nor  the 
FACC  coding  system  (from  DIGEST)  was  used.  This  is  because  DMA  did  not  direct  FACC 
codes  to  be  used  for  its  VPF  products  until  after  the  DCW  was  complete.  This  is  a  project 
sequencing  problem  that  will  be  rectified  in  future  editions  of  the  DCW. 


3.6  DCW  Standard  Operating  Procedures 

One  of  the  primary  objectives  of  developing  the  DCW  was  to  establish  standard  operating 
procedures  to  guide  database  production  and  subsequent  database  maintenance.  The 
development  of  SOPs  was  initiated  during  the  production  of  Prototype  3,  and  a  document 
describing  the  procedures  used  to  automate  the  database  layers  was  written.  The  document 
served  not  only  to  provide  guidelines  for  the  production  staff,  but  also  to  establish  standards 
for  database  maintenance. 

The  SOPs  were  written  and  issued  in  three  parts.  Part  One  described  standard  operating 
procedures  for  the  production  environment;  it  described  naming  conventions,  the  data 
dictionary  structure,  the  production  set  up,  and  automation  preparation.  Part  Two  described 
the  standard  operating  procedures  and  gave  detailed  instructions  for  data  layer  processing  in 
terms  of  creating  clean,  topologically  correct  ARC/INFO  layers  and  for  assigning  feature 
attributes.  Pan  Three,  which  was  prepared  upon  the  completion  of  separate  convertor 
documentation,  consisted  of  documentation  for  advanced  processing  steps,  specifically  edge 
matching  and  tiling.  Part  Three  also  described  the  division  of  the  thematic  data  layers  into 
libraries  based  on  the  tiling  scheme,  the  conversion  of  the  data  in  ARC/INFO  data  format  to 
VPF,  the  premastering  process,  and  the  division  of  the  VPF  data  into  geographic  regions  for 
CD-ROM  mastering  defined  by  the  geographic  organization  study.  The  SOPs  were  fully 
developed  through  iteration  procedures  from  the  prototypes  to  full-scale  production. 


3.7  Production  Organization  and  Methodology 

During  the  period  of  peak  production,  the  production  team  for  the  DCW  project  was  composed 
of  about  fifty  people  working  in  four  areas:  map  preparation,  scanning/digitizing,  data 
processing,  and  quality  assurance.  The  staffing  levels  in  these  groups  were  monitored  to 
achieve  a  steady  flow  of  production.  The  production  manager  was  in  charge  of  all  the 
production  work  and  coordination  with  technical  managers  and  production  group  leaders  in  all 
the  areas.  The  production  manager  called  a  technical  meeting  once  a  week  with  technical 
managers  and  group  leaders  to  find  out  the  status  of  the  work  and  whether  any  problems 
needed  to  be  resolved. 
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Because  of  the  large  amount  of  work  in  data  processing,  two  working  shifts  were  organized. 
Each  data  processing  working  team  was  assigned  three  ONC/JNC  map  modules.  For  those 
three  modules,  each  team  was  required  to  complete  all  basic  data  processing  and  attribute 
assignment  As  a  team  finished  one  map  it  was  assigned  another.  For  both  basic  data 
processing  and  attribute  assignment,  100  percent  quality  assurance  efforts  were  performed  to 
ensure  that  the  quality  of  work  would  meet  requirements.  Attribute  assignment  could  begin 
only  after  the  basic  data  processing  was  complete  and  the  QA  staff  determined  the  coverage  to 
be  clean  and  topologically  correct. 


3.8  Production  Procedures 

The  production  period  consisted  of  ramp-up,  full  production,  and  ramp-down  periods. 
Scanning  and  digitizing  was  initiated  in  September  1990  and  all  four  DCW  CD-ROMs  were 
created  in  "proof”  form  by  April  1992.  During  the  period  from  May  1992  to  August  1992, 
after  all  other  production  operations  had  been  completed,  DCW  product  packaging  took  place. 
Product  packaging  consisted  of  duplication,  packaging,  and  shipment  of  10,000  copies  of  the 
CD-ROMs  (along  with  VPFVIEW  software  and  user  documentation)  to  government 
distribution  points  in  Australia,  Canada,  the  United  Kingdom,  and  the  United  States.  (See 
Appendix  A  for  distribution  center  addresses.) 

To  increase  the  efficiency  of  the  production  and  establish  standard  procedures  in  processing, 
more  than  200  AMLs  were  developed  and  used  in  production.  These  AMLs  were  divided  into 
the  following  categories:  set-up  before  processing,  basic  data  processing,  attribution,  edge 
matching,  tiling,  check-plot  creation,  and  quality  assurance.  The  AMLs  contributed  not  only 
greater  production  efficiency  but  also  helped  make  data  consistent  The  use  of  AMLs  and  the 
continuing  development  of  additional  AMLs  during  the  production  period  resulted  in  a  three¬ 
fold  increase  in  production  efficiency  during  the  twenty  months  of  production. 

Preliminary  production  procedures  for  the  DCW  database  automation  were  developed  during 
the  design  and  prototyping  phase,  especially  during  Prototypes  3  and  4.  These  production 
procedures  were  described  in  the  DCW  SOPs.  Although  detailed  DCW  production  varied  from 
layer  to  layer,  in  general,  the  DCW  production  process  consisted  of  twelve  production  steps 
(exclusive  of  quality  control  operations,  which  will  be  described  below  in  Section  3.9).  These 
steps  are  listed  below. 

1 .  Photographic  reproduction  of  negative  separates 

2.  Map  preparation 

3 .  Scanning  and  digitizing 

4.  Basic  processing  and  initial  corrections 

5.  Attribute  assignment 

6.  Annotation  automation  and  final  corrections 

7 .  Transformation  and  edge  matching 

8.  Tiling 

9.  Conversion  to  VPF 

10.  Premastering 

1 1 .  Mastering 

12.  Packaging 
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3.8.1  Photographic  Reproduction  of  Negative  Separates 

The  primary  source  for  the  DCW  product  was  the  photographic  negative  feature  separates  of 
the  ONC  and  JNC  series  in  archive  at  the  Defense  Mapping  Agency  Aerospace  Center 
(DM AAC)  in  St  Louis,  Missouri.  These  separates  were  removed  from  archive  by  DMA  staff 
and  shipped  to  a  subcontractor,  GEONEX  Chicago  Aerial  Survey  of  Des  Plaines,  Illinois  for 
1:1  photographic  reproduction  of  frosted  acetate  positives  from  the  negative  source  separates. 

A  total  of  2,100  negative  separates  were  used  as  the  source  for  DCW  database  development 
and  were  photographically  reproduced  in  this  manner.  During  reproduction,  registration  marks 
were  photographically  reproduced  onto  each  separate,  ensuring  that  the  separates  could  be 
spatially  registered  during  the  digital  processes  that  would  follow.  After  reproduction,  the 
positive  frosted  acetate  separates  were  shipped  to  ESRI  for  further  processing  as  described 
below,  and  the  negative  separates  were  returned  to  DMAAC. 

3.8.2  Map  Preparation 

In  preparation  for  digitizing  and  scanning,  most  of  the  positive  frosted  acetate  separates 
underwent  a  "map  preparation"  process  in  which  features  already  present  were  enhanced  by 
drafting  scanning  aids  onto  the  separates.  The  positive  separates  had  many  feature 
characteristics  that  were  disadvantageous  for  scanning.  During  the  map  preparation  process, 
these  features  were  modified  to  improve  scanning  success.  A  list  of  features  that  were 
enhanced  through  manual  drafting  techniques  is  presented  in  Table  5. 

Tasks  within  map  preparation  were  defined  during  the  prototyping  process  based  on  a  resource 
utilization  analysis  also  conducted  during  prototyping.  This  resource  analysis  had  shown  that 
personnel  resources  would  be  more  effectively  spent  conducting  these  manual  map  preparation 
processes  before  scanning  rather  than  conducting  additional,  costly  interactive  editing  after  the 
scanning  process. 

An  independent  QC  check  for  the  map/data  preparation  was  performed  by  QC  staff  to  ensure 
that  activities  of  the  map  preparation  department  met  requirements  for  scanning,  digitizing,  and 
later  processing.  These  QC  steps  will  be  described  further  in  Section  3.9. 

3.8.3  Scanning  and  Digitizing 

Most  thematic  layers  present  in  the  DCW  were  scanned.  Layers  automated  through  digitizing 
were  usually  point  layers,  such  as  elevation  points  or  cultural  landmark  points.  During 
scanning,  each  frosted  acetate  separate  released  from  the  map  preparation  department  was  fed 
through  an  optical  platform  scanner.  The  scanner  electronically  captured  an  x,y  coordinate  grid 
of  positions  on  the  separate  in  raster  format  Since  the  film  separates  were  black-and-white,  all 
rasters  in  the  grid  were  either  "on"  or  "off."  The  rasters  that  were  "on/black"  represented  a 
gridded  depiction  of  the  features  present  on  a  particular  separate.  To  achieve  the  DCW  line 
accuracy  requirements,  scanner  resolution  was  typically  set  at  400  dots  per  inch  (DPI), 
although  many  dense  separates  (such  as  contour  separates)  were  scanned  at  500  DPL  No 
DCW  data  were  scanned  at  a  higher  resolution  than  500  DPL 

The  majority  of  separates  were  scanned  at  ESRI  using  a  raster  scanner  in  this  manner. 
However,  approximately  100  contour  separates  were  automated  by  the  subcontractor 
GEONEX  Chicago  Aerial  Survey  using  an  automation  processor  which  employed  line¬ 
following  algorithms  and  thus  skipped  the  vectorization  processes  described  below. 
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Table  5.  Enhancements  Completed  During  Map  Preparation 


Feature/Symbol 

Enhancement 

Intermittent  streams 

Solid  lines  were  drafted  through  the  discontinuous  dot- 
dashed  symbol  to  allow  scanner  recognition. 

Other  dashed  symbols  such  as  glacier  extent  lines  or 
utility  lines 

Solid  lines  were  drafted  through  the  discontinuous 
symbols  to  allow  recognition. 

Swamps 

On  the  separates,  swamps  were  indicated  through 
presentation  of  a  regular  pattern  of  point  symbols. 
Boundaries  around  the  swamp  were  drafted,  and  the 
scanner  captured  the  extent  of  the  swamp  area  as  a 
polygon  rather  than  capturing  thousands  of  pant 
symbols. 

Other  patterned  area  fills  such  as  sandy  areas, 
mangrove  vegetation,  fields,  salt  pans,  or  lava 
flows 

Boundaries  around  these  area  fills  were  similarly  drafted 
as  polygons  for  scanner  recognition. 

Connection  of  roads,  railroads,  utility  lines, 
contours,  boundaries,  and  other  linear  features 
broken  by  text  strings 

On  the  paper  chart  lithographs  for  ONCs  and  JNCs, 
linear  symbols  are  broken  by  text  strings  to  improve 
readability  of  the  text  When  the  chart  is  read  by  a 
human,  the  chart  user  mentally  inserts  the  missing 
pieces  of  the  linear  feature  into  place.  However,  use  of 
these  features  by  GIS  network  algorithms  requires  that 
they  be  continuous.  Therefore,  during  map  prepara¬ 
tion,  these  features  were  connected  on  the  separates 
through  manual  drafting  procedures. 

Connection  of  roads  and  railroads  through  urban 
area  polygons 

On  the  ONCs  and  JNCs,  roads  and  railroads  are  not 
connected  through  the  yellow  polygons  representing 
urban  areas.  For  360  major  cities  of  the  world, 
independent  map  sources  were  utilized  to  compile 
generalized  representations  of  the  urban  road  networks 
through  these  cities  during  map  preparation.  For  the 
remainder  of  cities  represented  as  polygons,  roads  and 
railroads  were  connected  through  the  cities  to  a  single 
point  and  thus  to  each  other  under  the  assumption  that 
road  and  railroad  traffic  would  pass  through  the  city  in 
some  manner.  Thus,  for  these  cities  the  correct 
geographic  locations  of  the  roads  and  railroads  were  not 
compiled  even  though  network  connectivity  is 
maintained 

Point  feature  attribution  coding 

During  map  preparation,  point  features  which  appeared 
frequently  and  which  had  generic  attributes  such  as 
"house,"  "farm,"  and  so  on,  were  assigned  a  code 
number  during  map  preparation.  These  codes  were  then 
related  to  appropriate  text  string  attributes  during 
digitization. 
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A  commercial  software  package  was  used  to  convert  the  scanned  raster  data  to  the  vector  data 
in  DXF.  The  package  utilized  an  algorithm  that  first  calculated  a  "casing"  or  frame  around  the 
rasters  representing  a  line  and  then  calculated  a  centerline  between  the  extremes  of  the  casing. 
As  noted  in  the  prototyping  discussion  in  Chapter  2,  an  algorithm  of  this  form  was  determined 
to  be  superior  in  terms  of  lmework  data  quality  to  so-called  "pealing  algorithms"  found  in  many 
vectorization  systems. 

An  advantage  of  the  vectorization  software  that  was  used  is  that  the  casings  that  were  created 
could  be  carried  forward  into  the  ARC/INFO  editing  process  and  used  as  a  "back-cover”  (or 
reference  coverage)  by  data  processors.  The  casing  back-cover  was  used  as  a  guide  by  the 
processors  so  that  any  movement  of  nodes  or  coordinates  that  they  introduced  could  be 
confined  to  a  movement  within  the  casing. 

Data  exiting  the  vectorization  software  were  in  DXF  format  The  DXF  data  were  next 
translated  into  the  ARC/INFO  data  format  using  a  specific  ARC/INFO  software  utility.  Four 
of  the  production  steps  described  below  were  carried  out  within  the  ARC/INFO  environment 

The  ARC/INFO  software  was  also  used  in  digitizing.  For  digitizing,  each  source  map 
manuscript  was  mounted  on  a  large-format  digitizing  board  and  registered  using  assigned  tics. 
The  x,y  coordinates  locating  feature  information  on  the  maps  were  electronically  captured  in 
vector  format  Each  feature  in  the  coverage  was  coded  with  a  unique  identification  code  for 
later  attribute  assignment 

At  the  conclusion  of  the  scanning/digitizing  process,  the  ARC/INFO  thematic  coverage  data 
were  located  in  the  file  server  in  the  production  computer  network  for  further  processing.  At 
this  point,  the  QC  department  verified  that  scanning  had  been  successful  and  that  basic 
processing  could  proceed  (see  Section  3.9). 

3.8.4  Basic  Processing  and  Initial  Corrections 

The  scanned  data  were  processed  to  create  a  clean  and  topologically  correct  ARC/INFO 
coverage  using  ARC/INFO  software.  This  basic  processing  step  was  the  first  of  four  steps 
conducted  exclusively  in  the  ARC/INFO  production  environment  The  major  interactive  work 
performed  by  data  processors  during  basic  processing  included: 

■  Conducting  the  "tic  transformation"  to  register  data  from  each  chart  separate  to  the  data 
from  all  other  separates  for  the  given  chart; 

■  Verifying  that  the  Root-Mean-Square  (RMS)  errors  for  the  transformation  were  within 
specification; 

■  Sorting  data  into  appropriate  DCW  layers  (there  is  not  a  one-to-one  correspondence 
between  ONC  separates  and  DCW  layers,  so  many  data  types  were  merged,  separated, 
or  otherwise  reorganized); 

■  Deleting  unnecessary  dangles  or  random  arcs  (many  of  which  were  the  result  of 
scanned  dust  spots,  scratches  in  the  source  separates,  or  failures  of  the  vectorization 
process); 

■  Linking  the  broken  lines  that  were  supposed  to  be  continuous; 
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■  Cleaning  the  scanned  module  boundaries  and  deleting  arcs  outside  the  boundaries; 

■  Digitizing  on-screen  any  features  that  were  misidenrified  in  the  scanning  and 
vectorization  processes; 

■  Separating  lines  that  were  incorrectly  joined  during  vectorization  (for  example,  touching 
contours  or  double-line  streams  that  had  collapsed); 

■  Enhancing  the  line  character  of  linework  (for  example,  showing  the  correct  angle  of 
intersection  of  roads  or  railroads  meeting  at  scute  angles  that  had  been  incorrectly 
intersected  during  vectorization);  and 

■  Creating  line  plots  for  verification  by  the  QC  department  that  basic  processing  was 
conducted  appropriately. 

Extensive  ARC/INFO  batch  operations  and  both  interactive  and  batch  AMLs  were  used  within 
this  process  to  support  the  data  processors.  The  digital  map  data  were  subjected  to  several 
rounds  of  electronic  and  visual  checks,  as  specified  in  the  QA  program,  to  produce  clean  digital 
map  sheets  that  accurately  matched  source  manuscript  maps  (see  Section  3.9). 

3.8.5  Attribute  Assignment 

During  attribute  assignment,  feature  attributes  were  assigned  to  their  associated  cartographic 
features.  Attribute  data  were  captured  using  several  methods.  Some  attribute  data  were  entered 
in  the  digitizing  process;  thus,  linework  and  attributes  were  captured  simultaneously  in  this 
case. 

The  most  common  method  of  assigning  attributes  for  scanned  data  was  to  code  features  directly 
on  computer  screen  after  clean  and  topologically  correct  layers  were  obtained  in  the  basic 
processing  step. 

Sometimes  AMLs  were  utilized  to  assign  the  codes  to  the  corresponding  features.  For 
example,  a  "contour  walking"  algorithm  was  designed  and  implemented  in  AML.  This 
algorithm  allowed  the  processor  to  assign  the  contour  attribute  value  to  a  single  contour;  the 
remaining  (1,000-foot  interval)  contours  were  assigned  through  the  algorithm.  In  a  second 
example,  inland  water  polygons  Oakes  and  double-line  rivers)  were  assigned  an  attribute  of 
"water  area"  through  a  series  of  production  processes  and  AMLs  in  which  polygons  were 
attributed  through  the  use  of  a  separate  point  coverage. 

Certain  attribute  data  already  existed  in  digital  format,  such  as  aeronautical  information  from 
DMA's  Digital  Air  Facilities  Information  File  (DAFIF).  These  data  were  electronically 
transferred  to  the  database  format  established  in  the  physical  database  design  before  being 
subjected  to  quality  assurance  checks. 

Again,  at  the  end  of  this  production  step,  significant  QC  activities  were  conducted  and 
additional  rounds  of  attribution  were  conducted  if  errors  were  identified.  QC  activities  at  this 
stage  of  the  process  relied  on  use  of  a  composite  plot  generated  on  an  electrostatic  plotter  (see 
Section  3.9). 
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3.8.6  Annotation  Automation  and  Final  Corrections 

Attribute  data  that  would  appear  within  the  DCW  as  text  were  entered  into  the  database  as 
annotation  layers.  Examples  of  annotation  included  place  names,  land  use  types,  cultural 
names,  and  river  names.  The  annotation  labels  were  entered  directly  into  the  annotation  layers 
as  a  graphic  entry  operation  at  the  keyboards  of  workstations.  To  aid  the  entry  operation,  a 
raster  display  of  the  text  was  presented  to  the  editor  (from  the  scanner  casing  files).  The  editor 
was  then  required  only  to  look  directly  at  the  screen  and  "overtype"  the  ASCII  annotation  data 
onto  the ;  rter  image  of  the  text  Entry  of  annotation  was  conducted  both  at  ESRI  and  a 
subcontractor — GEOCODE  of  Eau  Claire,  Wisconsin.  The  annotation  layers  were  subjected  to 
visual  quality  control  check  to  assure  proper  placement,  size,  and  spelling  of  the  map  text 
Diacritical  marks  were  not  entered  for  most  text  However,  text  containing  diacritical  marks 
were  sorted  into  layers  separate  from  other  text  so  that,  in  future  editions  of  the  DCW, 
diacritical  marks  can  be  added  to  the  text 

Based  on  errors  identified  from  a  visual  check  of  the  composite  plot,  and  other  automated  and 
visual  checks,  final  ARC/INFO  corrections  were  performed.  All  notes  were  reviewed  by  both 
the  QC  staff  and  the  processing  team  leader  for  the  layers  of  a  particular  map  sheet  to  ensure 
that  all  errors  identified  through  QC  processes  had  been  corrected  by  the  processing  staff. 

3.8.7  Transformation  and  Edge  Matching 

Graphic  edge  matching  is  the  process  of  connecting  (by  establishing  one  and  only  one  common 
node)  linear  or  polygonal  features  on  a  layer  of  a  particular  map  sheet  to  their  corresponding 
features  on  an  adjacent  map  sheet 

Before  edge  matching  could  occur,  all  map  sheets  needed  to  be  projected  into  a  common 
coordinate  system.  The  source  ONC  separates  use  a  Lambert  Conic  projection  based  on  a 
projection  from  the  central  meridian  of  each  map  sheet  Therefore,  transformation  information 
received  from  DMA  was  entered  into  a  batch  projection  algorithm,  and  each  sheet  was 
projected  to  a  common  Plate  Carree  projection.  The  Plate  Carree  projection  sets  longitude 
equal  to  latitude  so  that  plots  of  equal  quantities  of  latitude  and  longitude  (such  as  1  degree  by  1 
degree)  are  square. 

Graphic  edge  matching  was  performed  for  all  source  sheets  (linear  and  polygon  layers)  of  the 
DCW.  In  addition,  attribute  edge  matching  was  performed  throughout  die  DCW  database  to 
ensure  that  corresponding  feature  attributes  were  consistent  along  the  boundaries  of  map 
sheets.  Processors  who  conducted  edge  matching  rigorously  adhered  to  the  following  rule: 
the  least  accurate  of  the  automated  ONC/JNC  features  were  physically  moved  to  match  the 
most  accurate  features.  The  accuracy  information  for  each  of  the  ONC  and  JNC  sheets  was 
provided  by  DMA.  Code  plots  of  the  edge  matched  portion  of  all  sheets  were  created  in  order 
to  conduct  a  quality  control  check  to  verify  that  the  same  features  along  the  sheet  boundaries 
matched  both  graphically  and  by  attributes. 

3.8.8  Tiling 

A  fixed  5-by-5-degree  tiling  scheme  was  adopted  for  partitioning  the  DCW  database  into 
temporary  libraries.  Thus,  the  layers  of  each  edge  matched  sheet  were  partitioned  into 
5-by-5-degree  increments.  Following  partitioning,  each  layer  for  a  map  sheet  was  inserted  into 
its  appropriate  library  using  a  specifically  written  ARC/INFO  AML.  Next,  a  quality  control 
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AML  was  run  to  check  the  correctness  of  the  tiling  results.  The  DISSOLVE  function  in 
ARC/INFO  was  then  used  to  dissolve  the  edges  of  the  map  sheets  out  of  the  library,  so  that  the 
library  was  discontinuous  only  at  tile  boundaries.  (In  the  final  product,  tile  boundaries  do  not 
affect  data  continuity,  since  cross-tile  topology  is  created  during  the  conversion  to  VPF.) 

In  addition  to  the  quality  AML  noted  above,  visual  plots  of  the  data  libraries  both  before  and 
after  tiling  were  created  to  ensure  that  all  data  were  submitted  into  the  libraries  and  that  the 
fiJe/directory  references  for  the  tiled  data  were  correctly  created. 

3.8.9  Conversion  to  VPF 

Additional  major  tasks  consisted  of  converting  the  automated  ONC  and  JNC  data  in 
ARC/INFO  format  to  VPF  and  organizing  the  database  into  the  final  four  DCW  libraries.  The 
conversion  from  ARC/INFO  format  to  VPF  format  was  based  on  two  separate  sets  of 
programs — "set-up"  procedures  and  "translate"  programs. 

A  series  of  "set-up"  AMLs  (based  on  the  ARC/INFO  software)  were  first  run  to  carry  out  a  set 
of  stand-alone  processes  on  the  ARC/INFO  database.  Some  of  these  AMLs  called  C  programs 
to  build  VPF  winged-edge  and  cross-tile  topology.  Other  AMLs  built  user-defined  tables 
defined  by  the  DCW  product  specification  and  thus  were  very  specific  to  DCW  and  even  to 
coverages  within  DCW.  All  set-up  tools  were  run  from  within  a  single  UNIX  shell  script 
called  "Setup  Arc  VPF."  The  set-up  programs  built  a  set  of  INFO  program  files  known 
collectively  as  the  "conversion  interface  format"  This  format  was  documented  in  the 
ARC/INFO-to-VPF  Converter  Programmer  Documentation. 

After  completion  of  the  set-up  routines  and  creation  of  the  files  in  the  interface  format,  the 
translator  was  run  as  a  batch  program.  The  translator  is  a  fixed  set  of  C  routines  that  carry  out 
the  final  translation  from  the  interface  format  to  VPF  tables.  Since  this  software  operated  from 
a  defined  input  format,  it  does  not  change  for  any  VPF  product.  The  translator  converted  both 
INFO  files  from  the  set-up  procedures  and  additional  ASCII  files  that  were  translated  into  VPF 
metadata.  Metadata  is  the  descriptive  information  that  VPF  carries  in  header  tables  to  inform 
users  or  applications  software  about  the  contents  of  the  database. 

A  quality  check  was  performed  after  each  of  the  two  sets  of  procedures.  During  the  first  round 
of  quality  control  (after  running  the  "set-up"  AML),  feature  tables  were  checked  to  verify  the 
correctness  of  records,  and  feature  counts  were  conducted  to  ensure  that  all  features  had 
successfully  been  translated.  If  these  QC  processes  identified  any  errors,  the  set-up  procedures 
were  rerun.  After  running  the  translator,  the  VPFVIEW  program  was  utilized  to  allow  the 
visual  verification  of  graphic  displays  of  the  converted  data  on  the  screen.  In  addition,  a  batch 
program  entitled  VPFVERIF  was  then  run  to  check  the  relationships  between  the  feature  tables 
and  VPF  data  primitives  and  to  ensure  that  all  files  could  be  correctly  read.  These  QC  checks 
were  performed  on  every  layer  of  the  DCW  database. 

The  other  major  task  involved  in  this  post-processing  production  stage  was  organizing  the 
database  so  that  data  were  appropriately  placed  onto  the  four  DCW  CD-ROMs.  Based  on  the 
DCW  geographic  organization  study,  the  globe  was  organized  on  the  CD-ROMs  into  four 
geographic  areas:  North  America,  Europe/Northem  Asia,  South  America/Africa/ Antarctica, 
and  Southern  Asia/Australia.  Several  processes  were  conducted  to  organize  the  DCW  database 
onto  the  four  librai  les  with  appropriate  overlap  areas  as  defined  by  the  geographic  organization 
study. 
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3.8.10  Premastering 

Premastering  involved  the  preparation  of  data  for  CD-ROM  replication.  It  included  preparing 
tapes  for  shipment  to  the  premastering  subcontractor — GEOVISION  of  Norcross,  Georgia — 
and  a  series  of  activities  conducted  at  GEOVISION  involving  the  receipt,  handling,  and 
processing  of  data  and  its  ultimate  output  to  magnetic  tape  for  transmission  to  the  replicating 
facility. 

After  completion  of  the  ARC/INFO- to- VPF  conversion  process  described  above,  a  UNIX  shell 
program  was  executed.  The  UNIX  shell  called  a  series  of  subroutines  that  conduct  the 
following  process: 

■  Searches  for  and  deletes  empty  directories; 

■  Creates  batch  files  that  can  be  used  to 

—  Create  all  necessary  directories  for  the  DOS  premastering  partition,  and 
—  Include  all  directories  and  files  in  the  tape  writing  process; 

■  Creates  a  batch  file  that  can  be  used  to: 

—  Create  all  necessary  directories  for  the  ISO  9660  premastering  partition,  and 

—  Copy  data  from  the  DOS  premastering  partition  to  the  ISO  9660  partition. 

Two  of  the  three  batch  files  were  then  used  at  GEOVISION  during  the  additional  premastering 
processes  described  below.  These  file/directory  handling  processes  described  above  seem 
rather  simple  until  one  realizes  that  the  DCW  is  contained  in  over  150,000  files.  Thus,  the  file 
handling  operations  needed  to  be  automated  to  the  greatest  extent  possible.  Upon  completion 
of  the  shell  program,  all  data  and  batch  files  were  written  to  magnetic  tape  using  the  UNIX 
TAR  tape  writing  utility,  and  the  tapes  were  shipped  to  GEOVISION. 

At  GEOVISION,  commercial  CD  publishing  software  was  utilized  to  permit  ISO  9660- 
compatible  CD-ROM  data  preparation,  premastering  and  master  manufacturing  tape 
generation.  Tasks  involved  in  this  process  included: 

■  System  configuration 

■  Creation  of  the  DOS  directory  structure  based  on  using  the  results  of  the  shell  program 
described  above 
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■  Transfer  of  data  from  the  magnetic  tapes  to  the  DOS  partition 

■  Verification  that  the  data  in  the  DOS  partition  matches  that  of  the  magnetic  tape 

■  Creation  of  the  initial  ISO  9660  partition  using  DOS-like  commands  to  organize  files 
and  directories 

■  Creation  of  the  ISO  9660  directory  structure  and  transfer  of  the  data  into  the  ISO  9660 
partition  based  on  using  the  results  of  the  shell  program  described  above 

■  Organization  of  the  ISO  9660  directories  and  files  by  exact  physical  block  location  and 
size 

■  Simulation  of  the  performance  of  the  CD-ROM  utilizing  the  magnetic  media  partition 

■  Generation  of  the  master  manufacturing  tape,  and 

■  Shipment  of  the  master  manufacturing  tape  to  the  mastering  vendor. 

3.8.11  Mastering 

CD-ROM  mastering  was  conducted  at  the  Disc  Manufacturing,  Inc.  (DMI),  production  facility 
in  Huntsville,  Alabama.  In  general,  CD-ROM  mastering  steps  consisted  of  the  following 
activities: 

■  Laser  beam  recording  by  writing  the  bit  stream  from  the  master  manufacturing  tape  onto 
a  flat  glass  substrate  coated  with  a  thin  layer  of  photosensitive  material 

■  Monitoring  the  glass  master  creation  with  laser  quality  control  devices 

■  Electroplating  a  nickel  shell  onto  the  glass  master  to  create  the  "father  disc" 

■  Generating  a  "family"  of  nickel  stampers  through  electroplating 

■  Preparing  a  "stamper"  and  inserting  it  into  the  CD-ROM  press 

■  Pressing  (or  molding)  the  disc  onto  raw  polycarbonate 

■  Metalizing  the  molded  disc  with  an  aluminum  reflective  film 

■  Lacquering  the  metalized  disc  with  a  protective  varnish  by  dripping  the  lacquer  onto  the 
rotating  disc 

■  Conducting  automated  quality  control  operations  of  the  molding/coating  processes 

■  Printing  the  disc  label  directly  onto  the  protective  lacquer 

■  Conducting  quality  inspections  of  the  disc  label 
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■  Packaging  the  discs  into  their  jewel  cases  (in  the  case  of  the  DCW,  one  jewel  case 
containing  the  four  CD-ROMs  for  each  DCW  set) 

■  Inserting  the  disc  booklet  into  the  jewel  case 

■  Conducting  visual  quality  control  of  the  packaging  process 

■  Shrink-wrapping  the  jewel  case,  and 

■  Shipping  the  CD-ROMs  to  the  assembly  vendor. 

3.8.12  Packaging 

The  preceding  eleven  production  steps  were  all  conducted  during  the  period  from  September 

1990  until  April  1992.  By  April  1992, 150  "proof’  copies  of  each  of  the  four  DCW 
CD-ROMs  had  been  created  and  reviewed  by  DMA.  DCW  packaging  activities  occurred 
during  the  period  from  May  1992  until  August  1992.  During  the  DCW  product  packaging 
activity,  the  four  preliminary  CD-ROMs  were  duplicated  (10,000  copies  of  each),  packaged 
(along  with  10,000  copies  of  the  VPFVIEW  software  and  user  documentation),  and  shipped  to 
government  distribution  points  in  Canada,  the  United  Kingdom,  the  United  States,  and 
Australia. 

Packaging  elements  consisted  of  two  documents,  six  floppy  disks,  four  CD-ROMs,  and  the 
boxes  necessary  to  contain  them.  Package  design  took  place  primarily  during  the  latter  half  of 

1991  and  resulted  in  the  DCW  Package  Design  study.  Packaging  elements  and  subelements 
are  listed  here: 

■  VPFVIEW  1.0  Users  Manual  for  the  DCW ,  as  follows: 

—  Color  cover 
—  Text 
—  Barcode 

■  DOS  Installation  Instructions  for  the  DCW ,  as  follows: 

—  Black  and  white  cover 
—  Text 

■  Floppy  disks  containing  VPFVIEW  source  software,  VPFVIEW  executable  software, 
and  VPFVIEW  views,  as  follows: 

—  Three  3.5-inch  and  three  5.25-inch  floppy  disks 
—  Disk  envelope  and  label 
—  Three  3.5-inch  and  three  5.25-inch  disk  labels 
—  Six  bar  codes 
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■  CD-ROMs  containing  DCW  data,  as  follows: 

—  Four  CD-ROMs 

—  One  jewel  case  containing  the  four  CD-ROMs 
—  Jewel  case  front  cover 
—  Jewel  case  back  cover 
—  Insert  booklet 

■  Containers,  as  follows: 

—  Inner  container  (light  cardboard  box  enclosed  by  a  sleeve  primed  in  color) 

—  Outer  container  (heavy,  white  corrugated  cardboard  mailer — tuck  top  style) 

—  Outer  container  label/barcode 
—  Carton  containing  ten  mailers 
—  Pallet  set  containing  thirty-two  cartons 

Prior  to  DCW  product  assembly,  all  packaging  elements  were  printed  c.  otherwise  duplicated. 
CD-ROMs  were  stamped,  checked,  and  assembled  into  jewel  cases  at  DMI.  All  paper 
materials  were  printed  at  NORSTAR  Printing  Corporation  using  designs  developed  into 
camera-ready  copy  at  ESRI.  The  six  floppy  disk  masters  were  created  at  ESRI.  They  were 
duplicated  at  IPC  Software  Corporation.  Disk  duplication  quality  control  operations  at  IPC 
Software  included  verifying  the  absence  of  over  150  known  software  viruses  and  reading  back 
data  from  all  disks  that  were  duplicated. 

After  10,000  copies  of  all  DCW  packaging  elements  were  created,  IPC  Software  conducted 
product  assembly  of  all  packages,  including  assembly  into  cartons  and  pallet  sets.  Pallet  sets 
were  shipped  to  ESRI  for  final  inspection,  and  then  reshipped  to  government  distribution 
points.  All  packaging  activities  from  CD-ROM  duplication  to  shipping  were  accomplished 
over  a  period  of  fifteen  weeks. 


3.9  Quality  Assurance 


A  Quality  Assurance  (QA)  plan  was  developed  and  implemented  on  the  DCW  project  to  ensure 
that  all  products  conform  to  the  detailed  specifications  for  content  and  accuracy  agreed  upon  by 
the  participating  agencies.  DCW  quality  assurance  activities  were  identified  as  belonging  to 
four  overlapping  areas:  (1)  activities  supporting  effective  QA  for  the  project,  (2)  software 
development,  (3)  database  development,  and  (4)  CD-ROM  premastering  and  mastering.  The 
first  area  was  a  pivotal  component  of  the  DCW  project  infrastructure;  it  controlled  the  inputs 
and  outputs  of  the  product  development  process  and  ensured  the  quality  of  the  final  integrated 
project  deliverables.  The  other  three  areas  were  concerned  with  placing  controls  on  specific 
product  development  activities.  Of  the  three,  quality  assurance  efforts  focused  primarily  on 
database  development,  since  this  portion  of  the  project  was  the  most  complex  and  labor 
intensive. 


3.9.1  Activities  Supporting  Quality  Assurance 

Some  QA  activities  supported  a  number  of  aspects  of  the  project  and  were  product 
independent  Activities  in  this  area  consisted  of  well-defined  procedures  for  the  management 
of  materials  used  in  the  production  and  delivery  process,  including  the  receipt  and  transfer  of 
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materials,  internal  tracking  techniques  for  determining  the  status  of  the  project  and  the  position 
of  production  units  within  the  process,  product  archiving,  QA  evaluation  of  subcontractor 
activities,  the  review  of  in-house  staff  training,  and  test  procedures  for  peripheral  hardware. 
These  procedures  provided  effective  and  efficient  QA  for  DCW  production  activities  both  at  the 
main  production  facility  at  ESRI  and  at  subcontractor  establishments  outside. 

3.9.2  Software  Development  Quality  Assurance 

Software  QA  activities  were  performed  to  ensure  that  all  project  software  met  the  DCW 
requirements,  worked  soundly,  and  was  error  free. 

Two  categories  of  software  were  identified  for  the  DCW  project:  (1)  application  software,  and 
(2)  production  and  quality  control  software.  Each  software  had  distinct  QA  requirements. 
Application  software  refers  to  the  VPFVIEW  software  provided  with  the  product.  This 
software  had  a  sophisticated  user  interface  and  was  highly  integrated.  Production  and  quality 
control  software  refers  to  software  that  was  developed  specifically  to  assist  in  the  database 
development  effort  Within  the  ESRI  production  environment,  the  production  and  quality 
control  software  consisted  of  macro-level  programs  for  performing  specific  tasks,  such  as 
basic  data  processing  or  plot  generation. 

For  the  quality  assurance  of  application  software,  a  full  regime  of  unit  integration,  and 
functional  testing  was  performed.  All  testing  phases  were  guided  by  detailed  plans  for 
performing  the  work.  Unit  testing  was  performed  by  ESRI  staff.  Integration  testing  was 
performed  by  Loral  Defense  Systems — Akron  (LDSA).  Functional  testing  was  performed 
jointly  by  ESRI,  LDSA,  and  DMA.  (See  Section  2.5  for  a  more  detailed  description  of 
VPFVIEW  testing  activities.) 

To  make  sure  that  the  production  and  quality  control  software  met  DCW  production 
requirements,  a  Production  System  Software  Review  was  conducted  before  the  software  was 
placed  under  configuration  management  The  DCW  production  software  consisted  of  a  set  of 
independent  macro-level  programs  written  in  AML  and  INFO.  The  programs  were  developed 
to  handle  the  high- volume  data  processing  demands  of  DCW  production.  The  quality  of  output 
was  ensured  through  the  successful  generation  of  the  prototypes  and  maintained  through 
database  production  and  QA  feedback  during  implementation. 

The  Production  System  Software  Review,  which  was  dedicated  to  software  issues  and  to  the 
creation  of  a  unified  library  of  routines  to  form  the  basis  of  the  production  effort,  was 
conducted  to  ensure  the  quality  of  the  production  routines.  The  review  identified  standards  for 
internal  and  external  documentation,  the  functioning  of  the  user  interface,  and  operational 
consistency. 

3.9.3  Database  Development  Quality  Assurance 

Database  development  was  the  most  complex  portion  of  the  DCW  project  from  a  quality 
assurance  perspective.  It  involved  a  large  number  of  staff  members  performing  a  myriad  of 
activities  on  a  demanding  schedule.  The  quality  of  the  product  was  maintained  through  two 
primary  mechanisms:  (1)  detailed  data  quality  inspections  at  key  junctures  in  the  production 
process,  and  (2)  the  standardization  of  the  activities  performed  by  processing  staff  members. 
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The  DCW  database  development  process  can  be  viewed  as  consisting  of  six  primary  activities: 

(1)  map/data  preparation,  (2)  map  data  scanning/digitizing,  (3)  basic  data  processing, 

(4)  composite  plot  development,  (5)  edge  matching  and  tiling  verification,  and  (6)  VPF 
conversion  and  data  finalization.  Quality  control  work  focused  primarily  on  these  activities. 
(These  activities  correspond  to  production  steps  2  through  9  under  Section  3.8.) 

3.9.3. 1  Quality  Control  for  Map  Preparation 

Map  preparation  QC  for  the  frosted  acetate  separates  prior  to  scanning  or  digitizing  included 
checking  the  accuracy  of  registration  tics,  adding  logical  connectors  to  continue  the  linear 
features  broken  by  text  or  other  features,  checking  the  consistency  of  the  drafting  symbols  used 
by  the  map  preparer,  checking  the  connectivity  of  the  lines,  and  so  forth. 

3.9.3.2  Quality  Control  for  Scanning  and  Digitizing 

Scanning  and  digitizing  consisted  of  creating  vector  representations  of  ONC/JNC  features. 

The  vector  representatives  were  created  in  one  of  two  ways,  depending  on  the  feature  types  to 
be  automated.  In  general,  thematic  data  separates  bearing  linear  features  were  scanned  and 
those  bearing  point  features  were  digitized.  Scanning  and  digitizing  had  distinct  quality 
assurance  requirements. 

The  scanning  process  had  two  primary  steps:  scanning  and  vectorization.  After  the  scanned 
raster  data  were  converted  to  vector  data  using  vectorization  software,  QC  was  performed  on 
sample  areas  to  assess  the  adequacy  of  the  vectorization  parameters,  and  the  vector  data  were 
reviewed  on  the  screen  to  ensure  the  process  had  produced  vector  data  of  the  highest  quality. 
Another  QC  procedure  that  was  performed  was  to  compare  the  pretransfer  and  posttransfer  file 
sizes  for  consistency.  Then  the  vector  data  were  transferred  to  ARC/INFO  format  for 
processing  and  the  file  sizes  were  checked  again  for  consistency.  Vector  data  were  edited  in 
the  ARC/INFO  environment  After  initial  processing  in  the  ARC/INFO  environment  the 
processed  data  were  plotted  out  at  1: 1  scale  to  the  source  sheet  and  sent  to  the  QC  staff  for 
cartographic  accuracy  checking. 

The  digitizing  process  began  with  mounting  the  frosted  acetate  separate  on  a  digitizing  board. 
The  separate  was  then  registered  to  a  master  set  of  registration  points  using  the  affine 
transformation.  Acceptable  minimum  root-mean-square  (RMS)  error  tolerance  was 
0.004  inch.  In  instances  where  this  tolerance  could  not  be  achieved,  the  separate  was  taken 
down  and  compared  to  the  projection  separate  (the  sheet  standard)  to  determine  if  the  tics  were 
properly  aligned.  Any  tics  found  to  be  offset  were  eliminated  from  the  projection  set  In  some 
instances,  the  separates  had  become  distorted  as  the  result  of  the  environmental  changes,  in 
which  case  an  RMS  value  larger  than  the  set  tolerance  was  unavoidable.  RMS  errors  were 
recorded  in  the  digitizing  log.  After  the  digitizing,  the  data  were  plotted  out  at  1:1  scale  to  the 
source  sheet  and  made  available  to  the  QC  staff  for  cartographic  accuracy  checking. 

3.9.3.3  Quality  Control  for  Basic  Data  Processing 

Basic  processing  was  the  process  of  creating  topologically  correct  and  positionally  accurate  line 
work.  Quality  control  for  this  process  was  achieved  through  (i)  automatic  checking  and 

(2)  manual  checking. 
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Automatic  checking  entailed  using  the  utilities  in  ARC/INFO  or  specifically  written  AMLs  to 
verify  the  topological  structure,  to  check  the  polygons  for  labeling  errors,  to  check  the  coverage 
for  precision,  to  assess  error  tolerance  values,  and  so  forth. 

To  permit  manual  checking,  the  processed  data  were  plotted  out,  overlaid  on  the  original 
frosted  acetate  manuscripts  against  an  illumination  source,  and  reviewed  for  deviations  from 
the  source  map.  The  purpose  of  this  inspection  was  to  verify  cartographic  accuracy,  identify 
topology  violations,  and  verify  the  completeness  of  the  data.  Specifically  designed  marks  were 
used  to  denote  different  types  of  errors  to  guide  the  data  correction  process. 

After  the  QC  checks  were  finished,  the  check  plots  were  sent  back  to  the  processing  staff  for 
corrections.  This  cyclical  process  continued  until  all  known  errors  were  resolved.  Initial 
reviews  were  exhaustive;  subsequent  reviews  focused  on  verifying  that  previous  corrections 
were  performed  properly. 

3.9.3.4  Quality  Control  for  Attribute  Assignment 

During  attribute  coding,  cartographic  features  were  assigned  the  attribute  code  values  defined 
by  the  data  dictionary.  Attribute  code  accuracy  was  tested  by  using  a  combination  of  automated 
and  manual  techniques.  The  automated  attribute  QC  tests  were  performed  first  They 
consisted  of  valid  code  checks,  code  consistency  checks,  frequency  checks,  INFO  item 
checks,  and  others.  The  resulting  automated  attribute  QC  error  listings  were  used  by  the  QC 
staff  to  thoroughly  review  the  attribute  codings. 

As  a  manual  check,  plots  were  made  after  the  coding  process  was  completed  and  sent  to  the  QC 
staff  for  quality  checking.  The  quality  checking  was  facilitated  by  the  use  of  color  coding  and 
special  symbols  for  the  plots.  Independent  inspections  called  attribute  code  reviews  were  made 
of  100  percent  of  the  feature  attribute  codes.  An  iterative  process  of  QC  checking  was 
conducted  for  attribute  coding  until  all  known  errors  were  resolved. 

3.9.3.5  Quality  Control  for  Composite  Plots 

After  the  finalization  of  the  line  work  and  attribute  coding,  a  composite  plot  of  all  layers  was 
produced  on  a  color  electrostatic  plotter.  This  plot  was  reviewed  against  the  original  printed 
map  for  the  proper  relative  positioning  of  features,  and  for  data  omissions.  Statistics  on  the 
data  were  generated  at  this  time  as  well,  including  descriptions  of  data  attribute  fields, 
frequency  counts  of  data  attributes,  and  an  ARC  DESCRIBE  listing  providing  information  on 
number  of  features,  topology  status,  data  extent,  coverage  precisions,  and  edit  status. 

3.9.3.6  Quality  Control  for  Edge  Matching  and  Tiling 

A  transformation  process  was  conducted  which  consisted  of  joining  individual  production 
modules  (ONC  sheets)  into  a  seamless  database  and  then  partitioning  the  database  into  tiles. 
This  entailed  transforming  the  data  into  real-world  coordinates,  inverse  projecting  the  data  into 
decimal  degree  coordinates  (Platte  Carree  projection),  edge  matching  the  individual  tiles,  and 
merging  and  partitioning  the  data  into  tiles  using  Map  LIBRARIAN  program  of  ARC/INFO. 

After  the  data  were  projected  into  decimal  degree  coordinates,  a  plot  was  made  of  registration 
tics  with  identifiers  for  review  by  the  quality  control  staff  to  ensure  that  coordinate 
transformations  and  projections  on  all  layers  had  been  performed  correctly. 
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A  series  of  plots  covering  only  map  sheet  edges  were  produced  for  edge  matching  QC.  The 
QC  staff  then  manually  indicated  links  between  features  on  adjacent  charts.  When  mismatches 
were  identified,  the  QC  staff  used  the  more  accurate  sheet  as  the  criterion.  Corrections  were 
then  made  by  the  processing  staff  in  an  ARCEDIT  environment;  the  least  accurate  features  were 
moved  to  match  the  positions  of  the  most  accurate  features. 

After  sheet  merging  and  tile  partitioning,  a  set  of  tiles  was  arbitrarily  selected  and  a  series  of 
diagnostic  statistics  were  run  on  them;  a  visual  review  was  performed,  and  a  listing  of  selected 
records  from  the  primary  attribute  tables  was  generated.  This  information  was  compared  later 
to  the  same  information  after  the  data  were  converted  to  VPF. 

3.9.3.7  Quality  Control  for  VPF  Conversion  and  Data  Finalization 

Once  the  database  was  completed  in  ARC/INFO,  it  was  converted  to  VPF  and  restructured 
according  to  the  CD-ROM  geographic  organization.  At  this  time,  tne  primary  data  quality 
concerns  were  completeness  and  correctness  of  the  conversion  process. 

Conversion  software  converted  the  ARC/INFO  data  into  VPF  format  on  a  tile-by-tile  basis, 
renamed  individual  files  and  directories,  and  organized  the  data  in  a  manner  that  was  consistent 
with  the  DCW  product  specification.  In  addition,  all  data  were  visually  reviewed  in  VPFVIEW 
for  completeness  and  to  verify  that  attribute  tables  were  correct  and  intact  Automated  checks 
were  also  run  to  verify  completeness  and  the  integrity  of  the  internal  data  structure.  These 
automated  checks  included  feature  count  comparisons,  as  well  as  tests  for  proper  relationships 
between  feature  table  records  and  primitives,  and  topological  relationships.  Taken  together, 
these  processes  served  to  verify  completeness  and  correctness  in  a  comprehensive  fashion. 

This  process  was  repeated  until  all  known  errors  were  corrected. 

3.9.4  Quality  Control  for  CD-ROM  Production 

The  CD-ROM  manufacturing  process  consisted  of  two  primary  tasks:  (1)  premastering  and 
(2)  mastering.  Quality  assurance  for  each  task  entailed  different  activities. 

3.9.4.1  Quality  Control  for  CD-ROM  Premastering 

Quality  control  for  CD-ROM  premastering  focused  on  a  series  of  data  verifica^ns,  including 
the  completion  of  transfer  tape  transmittal  forms  for  the  nine-track  tape,  transfer  tape  QC 
reports,  and  the  completion  of  tape  transmittal  forms  for  the  premastering  tape. 

The  first  step  in  premastering  was  to  transmit  the  digital  data  on  nine-track  tape  from  ESRI  to 
the  premastering  subcontractor  (GEOVISION,  Inc.).  ESRI  used  standard  digital  tape 
transmittal  procedures  and  transfer  tape  transmittal  forms  in  documenting  the  process.  The 
recorded  information  included  file  names,  byte  counts,  and  file  sequence/ID  numbers  for  all 
files,  which  were  organized  by  CD-ROM  disc  number. 

Next,  GEOVISION  loaded  the  data  from  tape  and  compared  what  was  received  from  ESRI 
with  the  description  on  the  transfer  tape  transmittal  form.  The  result  of  this  process  was  a 
transfer  tape  QC  report.  The  report  listed  any  discrepancies  found  and  corrective  actions  taken 
and  indicated  any  further  ESRI  action  that  might  be  necessary. 
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GEOVISION  reformatted  the  data  and  conducted  a  series  of  tests  in  which  the  behavior  of  the 
data  on  the  CD-ROM  media  was  simulated.  After  the  tests  were  successfully  concluded, 
GEOVISION  transferred  the  data  to  the  mastering  subcontractor  (Disc  Manufacturing,  Inc.,  or 
DMI)  on  a  master  manufacturing  tape.  Prior  to  this  step,  a  premaster  tape  transmittal  form  was 
completed,  documenting  the  data  characteristics  at  the  time  of  shipment,  and  sent  to  ESRI  for 
review. 

Upon  receipt  of  the  data,  DMI  initiated  a  disc  mastering  process.  DMI  also  provided 
GEOVISION  with  a  premastering  tape  vendor  QC  report  of  the  data  characteristics.  A 
premaster  tape  vendor  verification  report  was  also  generated  by  GEOVISION  after  an  extensive 
comparison  of  data  characteristics  was  completed. 

3.9.4.2  Quality  Control  for  CD-ROM  Mastering 

CD-ROM  mastering  was  the  production  of  master  "molds."  For  mastering,  the  primary 
objective  of  quality  control  was  to  monitor  the  physical  characteristics  of  the  discs.  After 
producing  the  first  set  of  CD-ROMs,  DMI  provided  ESRI  with  a  stamper  quality  control 
report  The  report  consisted  of  the  results  of  internal  tests  conducted  on  the  model  used  to 
press  the  CD-ROM  discs.  The  next  step  connected  with  CD-ROM  mastering  was  to  test  the 
discs.  The  results  of  these  tests  were  documented  in  a  test  disc  and  stamper  verification  report 
which  presented  the  level  of  the  physical  and  data  integrity  for  ESRI's  approval  or  disapproval. 
The  functional  testing  of  the  discs  was  also  undertaken  at  this  time.  At  ESRI,  the  functional 
testing  concentrated  on  data  access  through  the  application  software;  at  GEOVISION,  it 
concentrated  on  disc  readability  on  a  variety  of  platforms.  Discrepancies  found  were  listed  in  a 
QC  report,  and  corrective  action  was  taken. 

Following  acceptance  of  the  test  product,  ESRI  gave  DMI  permission  to  proceed  with 
CD-ROM  production.  The  final  disc  production  report  and  QC  report  were  completed  after  the 
final  test  was  conducted  on  the  actual  CD-ROM  production  run. 


3.10  Desert  Shield/Desert  Storm  Support 

3.10.1  Introductlon/Objective 

In  August  of  1990,  DMA  asked  ESRI  to  provide  GIS  support  for  the  U.S.  government  This 
support  consisted  of  data  conversion  of  existing  City  Graphic  (CG),  JOG,  Tactical  Pilotage 
Chart  (TPC),  and  ONCs  of  the  Persian  Gulf  region.  The  ONC  effort  was  performed  as  a  part 
of  the  overall  DCW  project  The  scales  of  the  source  data  are  1:12,500  and  1:25,000  for  the 
CGs,  1:250,000  for  the  JOG,  1:500,000  for  the  TPC,  and  1:1,000,000  for  the  ONCs. 

The  TPC  and  ONC  databases  were  automated  in  accordance  with  the  DCW  database  design. 
The  CG  and  JOG  databases  were  automated  in  accordance  with  a  database  design  supplied  by 
DMA.  This  database  design  used  the  FACS  coding  system  as  established  in  DMA’s  Digital 
Production  System. 

3.10.2  History 

In  August  of  1990,  DMA  asked  ESRI  to  provide  GIS  support  for  the  U.S.  government's 
participation  in  Operation  Desert  Shield.  ESRI  began  converting  CG  charts  under  the  DCW 
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contract  at  the  beginning  of  September  1990.  The  cor  'ersion  schedule  was  very  short  and  did 
not  allow  sufficient  time  to  edge  match  the  ARC/INFO  databases.  All  data  layers  were 
captured  and  delivered  in  early  October. 

The  JOG  conversion  effort  began  in  October  with  a  pilot  consisting  of  two  JOG  charts.  All 
data  were  captured  following  FACS  guidelines.  The  pilot  also  investigated  the  feasibility  of 
using  automation  subcontractors  in  order  to  meet  the  rigorous  production  schedule.  The  JOG 
conversion  project  was  completed  in  March  1991.  The  TPC  effort  began  in  October  and  was 
delivered  in  December  1991,  and  the  ONC  effort  was  incorporated  into  the  ongoing  DCW 
project 

3.10.3  Production 

This  section  describes  production  issues  concerning  the  design  and  production  procedures  for 
the  product. 

3.10.3.1  City  Graphics  Conversion 

In  late  August  1990,  ESRI  received  notification  that  seven  City  Graphic  charts  needed  to  be 
converted  to  ARC/INFO  format  At  that  time,  two  DMA  representatives  came  to  ESRI  to 
review  the  proposed  database  design  and  to  resolve  any  production  questions.  The  data 
sources  were  photographic  positive  films.  Each  film  positive  contained  different  feature  types. 
Transportation  data  appeared  on  multiple  film  separates.  Some  transportation  line  features  for 
the  Kuwait  City  charts  were  generalized  as  a  result  of  the  nature  of  the  data  source.  DMA  and 
ESRI  staff  determined  that  the  integration  of  these  separates  was  best  performed  by  drafting  all 
lines  onto  new  film  manuscripts.  These  manuscripts  were  scanned  and  then  processed.  Three 
1:12,500  CG  charts  for  Kuwait  City  and  four  1:25,000  CG  charts  for  Baghdad  were  captured 
in  ARC/INFO. 

Each  separate  was  scanned  and  converted  into  vector  format  as  a  single  coverage.  All 
coverages  were  transformed  using  one  set  of  master  tics.  Each  coverage  was  edited  and  coded 
according  to  data  sources.  After  basic  processing  and  coding,  each  production  coverage  was 
separated  into  the  ten  layers  specified  in  the  database  design.  These  final  coverages  were  edge 
matched,  transformed,  and  then  projected  to  decimal  degrees.  Because  of  the  two  different 
scales,  Kuwait  City  roads  were  captured  as  parallel  lines  with  a  median  polygon  in  between, 
whereas  Baghdad  roads  were  captured  as  single  lines.  All  Kuwait  City  buildings  were 
captured  as  polygons,  whereas  Baghdad  buildings  were  captured  as  points.  The  Kuwait  City 
data  did  not  contain  tinted  urban  areas;  urban  areas  for  Baghdad  were  captured  as  polygons. 

The  database  design  was  based  on  the  Feature  Attribute  Coding  Dictionary  (FACD).  Briefly, 
the  FACD  separates  all  features  into  ten  layers:  CUL1  (culture  1),  CUL2  (culture  2),  TRNS 
(transportation),  VEG  (vegetation),  ELEV  (elevation),  COMM  (communication),  PHYS 
(physiography),  HYDR  (hydrography),  GEN  (general),  and  BND  (boundaries).  All  layers 
were  converted  except  ELEV  (Elevation).  Each  feature  attribute  table  contains  only  the  record 
ID  and  the  FACS  code  of  the  feature.  All  attributes  for  a  given  coverage  were  split  into 
different  tables  based  on  their  FACS  codes.  This  meant  that  each  table  for  a  particular  coverage 
needed  a  different  set  of  attributes. 

Many  of  the  features  in  the  City  Graphic  data  sets  were  not  fully  supported  by  FACS  or  not 
clearly  described  in  the  digital  City  Graphic  product  specification;  these  features  were  coded 
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with  nonstandard  FACS  codes  or  attributes.  Many  features  could  not  be  interpreted  from  the 
data  sources  and  therefore  could  not  be  clearly  defined  by  FACS.  These  instances  were  fully 
reviewed  with  DMA  and  documented. 

3.10.3.2  Joint  Operations  Graphic  Conversion 

In  October  of  1990,  ESRI  was  notified  that  JOG  charts  needed  to  be  converted  to  ARC/INFO 
format.  The  data  source  was  photographic  positive  films.  Each  film  positive  contained 
different  feature  types.  As  specified  in  the  database  design,  six  JOGs  were  converted  into 
ARC/INFO  format  with  all  layers,  except  elevation.  Twenty-two  JOGs  were  converted  with 
only  the  following  features:  all  roads  (including  tracks),  hydrography  (except  intermittent 
drainage,  swamps,  or  land  subject  to  inundation),  population  point  and  polygons,  and 
international  boundaries. 

Each  separate  was  scanned  and  converted  into  vector  format  as  a  single  coverage.  All 
coverages  were  transformed  using  one  set  of  master  tics.  Each  coverage  was  edited  and  coded 
according  to  data  sources.  The  database  design  used  for  the  JOG  conversion  was  essentially 
the  same  as  that  used  for  City  Graphic  conversion. 

Many  of  the  features  in  the  JOG  data  sets  were  not  fully  supported  by  FACS  or  not  clearly 
described  in  the  digital  JOG  product  specification;  these  features  were  coded  with  nonstandard 
FACS  codes  or  attributes.  Many  features  could  not  be  interpreted  from  the  data  sources  and 
therefore  could  not  be  clearly  defined  by  FACS.  These  instances  were  fully  reviewed  with 
DMA  and  documented. 

3.10.3.3  Tactical  Pilotage  Chart  and  Operational  Navigation  Chart  Conversion 

In  October  of  1990,  ESRI  received  notification  that  three  TPC  charts  and  one  ONC  needed  to 
be  converted  to  ARC/INFO  format.  The  data  source  was  photographic  positive  films.  Each 
film  positive  contained  different  feature  types.  A  decision  was  made  by  DMA  to  convert  the 
TPC  charts  using  the  database  design  being  developed  for  the  ONCs  for  the  DCW  database. 
This  database  design  included  the  following  layers: 

■  Cultural/political  data  layers:  political/oceans,  populated  place,  railroads,  roads,  and 
utilities. 

■  Surface  information  data  layers:  drainage,  supplemental  drainage  hypsography, 
supplemental  hypsography,  land  cover,  ocean  feature,  and  physiography. 

■  Aeronautical  information  data  layers:  aeronautical,  cultural  landmarks,  transportation 
structure,  and  vegetation. 

■  Data  quality  information  data  layer:  data  quality. 

These  coverages  were  created  and  processed  using  the  SOPs  from  the  DCW  production 
project. 
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4.1  Digital  Nautical  Chart 

The  DCW  project  set  the  stage  for  a  series  of  additional  ESRI  projects  for  the  Defense  Mapping 
Agency:  the  Digital  Nautical  Chart  (DNC)  project  and  the  Vector  Smart  Map  (VSM)  project 
This  work  is  designed  to  meet  the  growing  demand  for  military  GIS  analysis  using  data  in 
VPF. 

4.1.1  Introduction 

In  an  additional  application  of  the  VPF  standard,  ESRI  is  producing  a  prototype  database 
formatted  in  VPF  that  will  be  used  to  support  computerized  marine  navigation.  The  DNC 
project  is  a  pilot  program  that  will  provide  the  U.S.  Navy  and  the  U.S.  Coast  Guard  with 
digital  hydrographic  and  topographic  data  on  CD-ROM  for  the  Norfolk,  Virginia,  and 
New  York  City  harbor  areas.  These  prototype  databases  will  contain  up  to  fourteen  data 
layers,  including  port  facilities,  aids  to  navigation,  limits,  obstructions,  and  hydrography. 

4.1.2  DNC  Project  Objectives 

Four  objectives  were  identified  for  the  DNC  project. 

■  To  provide  proof  of  concept  for  a  digital,  geographically  based,  nautical  chart  display 
and  navigation  system. 

■  To  provide  an  opportunity  for  evaluating  the  DNC  system  through  the  use  of 
prototypes. 

■  To  conduct  tests  on  site  that  simulate  actual  working  conditions. 

■  To  demonstrate  GIS  database  applications. 

4.1.3  Design  Overview 

The  intention  of  the  project  was  to  create  a  series  of  DNC  prototype  databases  structured  in 
VPF.  For  each  DNC  prototype,  DMA  is  providing  a  product  specification  that  describes  the 
feature  content,  accuracy,  and  data  format.  The  FACC  coding  scheme  is  being  used  to  code 
the  features  and  attributes  in  the  most  recent  prototype  of  the  DNC. 
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4.1.4  DNC  Database  Content 

The  DNC  database  is  divided  into  four  libraries  based  on  the  type  and  scale  of  the  source 
charts. 


■  The  General  library  at  a  scale  of  1:500,000  or  smaller 

■  The  Coastal  library  at  a  scale  of  1 :75, 000-1 : 500,000 

■  The  Approach  library  at  a  scale  of  1 :25,000-1 : 100,000 

■  The  Harbor  library  at  a  scale  of  1 : 10,000-1 :50,000 

Up  to  fourteen  thematic  coverages  were  identified  for  each  library:  Cultural  Landmarks,  Earth 
Cover,  Inland  Waterways,  Land  Cover,  Relief,  Port  Facilities,  Aids  to  Navigation, 
Obstructions,  Hydrography,  Environment,  General  Information  Limits,  Caution  Limits, 
Avoidance  Limits,  and  Navigation  Limits. 

4.1.5  Production 

The  database  for  the  DNC  prototypes  consists  of  information  extracted  from  nautical  charts 
published  by  the  National  Ocean  Service  (NOS).  In  general,  the  production  of  the  digital  DNC 
database  from  hard  copy  source  requires  the  same  processes  as  used  for  the  DCW: 

■  Chart  preparation  (review  for  content  and  quality) 

■  Scanning  and  digitizing  (convert  the  chart  data  to  digital  data) 

■  Cartographic  editing  (check  the  data  for  positional  accuracy,  eliminate  errors,  and  build 
topology) 

■  Attribute  coding  (code  features  with  their  proper  attributes  in  accordance  with  the 
product  specification) 

■  Finalization  (edge  match  and  tile) 

■  Convert  to  VPF 

■  Distribute  data  on  CD-ROM  in  VPF. 

4.1.6  Development  Status 

The  DNC  project  is  being  developed  in  four  prototypes,  with  each  prototype  involving  a  larger 
and  more  complex  data  set 

4.1.6.1  Prototype  1A:  Floppy  Disk  Data  Sampler 

Prototype  1 A  consisted  of  5-by-5-minute  subsets  of  the  data  digitized  for  DCW  Prototypes  2 
and  3.  DCW  TYPE  and  STATUS  codes  were  used  to  code  the  features  and  attributes.  The 
automated  data  were  converted  to  VPF  and  delivered  to  DMA  on  floppy  disk  in  November 
1991. 
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4.1.6.2  Prototype  IB:  Magnetic  Tape  Data  Sampler 

Prototype  IB  consisted  of  data  from  NOS  Chart  12245  that  were  digitized  for  DCW 
Prototypes  2  and  3.  Feature  attributes  were  coded  in  accordance  with  the  FACS  attribute 
coding  scheme.  The  data  were  converted  to  VPF  data  structure  and  delivered  to  DMA  on 
magnetic  tape  in  January  1992. 

4.1.6. 3  Prototype  2:  CD-ROM  Data  Sampler 

Prototype  2  consists  of  data  extracted  from  six  NOS  charts  of  the  Norfolk,  Virginia,  area.  The 
feature  attributes  were  assigned  in  accordance  with  FACS.  The  data  were  converted  to  VPF 
and  delivered  to  DMA  on  CD-ROM  in  June  1992. 

4.1.6.4  Prototype  3:  CD-ROM  Data  Sampler  in  FACC 

Prototype  3  will  include  five  additional  charts  from  the  New  York  harbor  area  in  addition  to  the 
six  NOS  charts  of  the  Norfolk,  Virginia,  area.  All  features  will  be  assigned  with  the  codes  in 
accordance  with  FACC.  The  data  will  be  converted  to  VPF,  with  multiple  feature  classes  and 
join  tables.  CD-ROM  will  be  used  as  the  storage  medium.  Prototype  3  will  be  delivered  to 
DMA  in  December  1992. 

4.1.7  Source  Materials 

DNC  Prototype  2  was  populated  with  the  feature  content  of  six  NOS  charts  from  tie  Norfolk, 
Virginia,  area. 


Chart  Number 

Scale 

Chart  Type 

12200 

1:419,706 

Coastal 

12207 

1:80,000 

Approach 

12221 

1:80,000 

Approach 

12222 

1:40,000 

Harbor 

12245 

1:20,000 

Harbor 

12254 

1:20,000 

Harbor 

DNC  Prototype  3  will  include  five  additional  charts  from  the  New  York  harbor  area: 


Chart  Number 

Scale 

Chart  Type 

13003 

1:1,200,000 

General 

12300 

1:400,000 

Coastal 

12327 

1:40,000 

Harbor 

12339 

1:10,000 

Harbor 

12366 

1:20,000 

Harbor 
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4.1.8  Summary 

If,  in  the  future,  the  requirements  of  ship  navigation  can  be  met  by  using  VPF  databases 
published  on  CD-ROM  instead  of  by  using  the  traditional  paper  chart,  significant  onboard 
space  savings  will  be  realized.  More  important,  because  VPF  digital  databases  will  be  able  to 
be  updated  more  frequently  than  paper  charts,  they  will  provide  more  current  information  about 
naval  hazards  and,  thus,  safer  navigation.  In  addition,  DNC  data  may  permit  the 
implementation  of  a  concept  called  "interactive  navigation."  Interactive  navigation  would  allow 
navigators  to  chart  course  after  evaluating  a  number  of  variables,  including  depth,  navigation 
limits,  and  obstructions. 


4.2  VSM  Development 

4.2.1  Project  Objective  and  Scope 

To  support  the  establishment  of  the  VPF  standard,  DMA  tasked  iiSRI  to  develop  product 
specifications  and  prototype  databases  for  a  third  VPF  digital  product  series  for  GIS 
applications.  The  product  specifications  and  prototype  databases  described  below  are  designed 
to  support  the  VSM  program.  The  product  specifications  will  reflect  the  current  VPF  standard. 

The  VSM  project  will  entail  the  production  of  two  databases.  A  high-resolution  database  will 
contain  data  converted  from  high-resolution  sources,  such  as  sources  at  1:50,000  or  1:100,000 
scale.  A  medium-resolution  database  will  contain  data  converted  from  medium-resolution 
sources,  such  as  the  1 :250,000-scale  Joint  Operations  Graphic  charts  (JOGs). 

Two  prototypes  of  each  database  are  to  be  developed.  The  first  prototype  will  use  the  Feature 
Attribute  Coding  System  (FACS).  A  second  prototype  has  been  proposed  to  implement  the 
Feature  Attribute  Coding  Catalogue  (FACC). 

4.2.2  Project  History 

The  VSM  project  began  in  December  1991  as  a  modification  of  the  basic  DCW  contract.  At 
DMA  request,  ESRI  considered  several  design  options,  including  using  the  digital  JOG  as  a 
data  source.  The  design  was  presented  to  DMA  in  February  1992,  when  the  following  issues 
were  discussed:  the  thematic  layers  to  be  included  in  the  database;  the  features  to  be  included  in 
the  databases;  the  attributes  and  attribute  values  for  each  feature;  and  the  implementation  of  the 
VPF  standard  in  the  VSM  design. 

A  draft  of  the  product  specification  was  submitted  to  DMA  in  July  1992.  The  medium- 
resolution  and  high-resolution  data  were  digitized  from  government-furnished  film  separates. 

4.2.3  Characteristics  of  Database  Designs  and  Product  Specifications 

The  design  for  the  two  VSM  databases  is  based  on  the  VPF  standard.  Mandatory  VPF  tables 
and  reference  libraries  (one  per  database)  are  carried  at  the  database  level.  One  library  reference 
coverage  and  one  tile  reference  coverage  for  each  library  are  carried  at  the  library  level,  as  are 
other  mandatory  VPF  tables. 
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The  design  for  the  medium-resolution  and  the  high-resolution  databases  are  identical  at  the 
library  level.  At  the  coverage  level,  the  differences  between  the  databases  reflect  the 
differences  between  the  features  and  their  attributes.  These  differences  are  also  reflected  in  the 
different  feature  classes  in  the  medium-  and  high-resolution  libraries. 

The  main  portions  of  the  VSM  product  specifications  describe  the  implementation  of  the  VPF 
standard  at  the  database  level.  Appendixes  contain  the  tables  for  the  high-  and  medium- 
resolution  libraries. 
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In  the  United  States,  Latin  America,  Asia,  and  Africa: 

U.S.  Geological  Survey 
ESIC — Open  File  Section 
Box  25286 
Federal  Center 
Mail  Stop  517 
Denver,  CO  80225 
U.S.A, 

Tel:  (303)  236-7476 


(U.S.  Dept  of  Defense  users  may  contact) 

Defense  Mapping  Agency 
Combat  Support  Center 
Attn:  PMSC/D-16 
6001  MacArthur  Blvd. 

Bethesda,  MD  20816-5001 

Tel:  (301)227-5518 


In  Canada* 

Products  and  Services  Division 
Surveys,  Mapping,  and  Remote 
Sensing  Sector 

Energy,  Mines  and  Resources  Canada 
615  Booth  Street,  Room  400 
Ottawa,  Ontario 
CANADA  K1A0E4 

Tel:  (613)995-2123 
Fax:  (613)995-6001 


In  Europe: 

Chadwyck-Healcy  Ltd. 
Cambridge  Place 
Cambridge  CB2  1NR 
UNtTED  KINGDOM 

Tel:  (0223)311479 
Fax:  (0223)66440 


In  Australia: 

The  Manager 
AUSMAP  Data  Unit 
P.O.  Box  2 

BELCONNEN  ACT  26 1  / 
Australia 


(Defense  users  may  contact) 

Directorate  of  Geographic  Operations 
National  Defence  Headquarters  (NDHQ) 
Surveys  and  Mapping  Bldg. 

Ottawa,  Ontario 
CANADA  K1 A 0K2 

Tel:  (613)992-7666 
Fax:  (613)996-3328 


(Defense  users  may  contact) 

Requirements  Division 
Geo  Commitments  Group 
Elmwood  Avenue 
Feltham 

Middlesex  TW137AH 
UNITED  KINGDOM 


Tel:  (081)  890  3622  ext  4134 
Fax:  (081)  890  3622  exL  4148 


(Defense  users  may  contact) 

Directorate  of  Survey-Army 
Campbell  Park  Offices 
Building  CP2-4-2 4 
CAMPBELL  ACT  2601 
Australia 
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A  training  plan  was  prepared  to  transfer  the  technology  of  the  VPF  standard.  The  training  plan 
provides  for  a  combination  of  classroom  instruction,  audiovisual  aids,  demonstrations,  and 
hands-on  practice  to  demonstrate  VPF  concepts  and  design;  automated  routines  for  database 
transfer  to  VPF;  and  the  system  architecture  of  the  VPFVIEW  application  software. 

A  modular  approach  was  taken  to  the  training  plan.  Each  module  is  a  self-contained  unit  with 
unique  prerequisites  and  learning  objectives  that  are  to  be  met  within  the  module.  The  modules 
can  be  tailored  to  the  needs  of  those  in  the  class.  The  training  program  focuses  on  training 
DMA  staff,  but  the  modularity  of  the  training  program  will  make  it  adaptable  to  other  groups. 
The  modules  and  courses  are  listed  below. 

Module  1 — VPF  Dam  Conversion  and  CD-ROM  Premastering 

Module  1  consists  of  two  courses:  the  conversion  of  data  to  VPF,  and  the  premastering  of 
VPF  data.  Metadata  generation  and  quality  control  for  VPF  data  will  also  be  discussed. 

Course  1:  Preparing  and  Converting  a  Database  into  VPF.  The  goal  of  this  course  is  to  train 
DMA  personnel  in  the  production  procedures  required  to  prepare  a  database  for  conversion  to 
VPF,  and  the  procedures  required  to  convert  a  database  to  VPF. 

Course  2:  VPF  Database  Premastering.  The  goal  of  this  course  is  to  train  DMA  personnel  in 
the  production  procedures  required  to  generate  complete  premastering  Files  from  a  VPF 
database,  and  give  them  insight  into  the  premastering  process.  The  course  also  reviews 
procedures  for  conducting  the  premastering  process,  including  the  preparation  of  a  tape  for 
delivery  to  a  mastering  vendor. 

Module  2 — Introduction  to  the  VPF  Standard  and  Concepts 

The  goal  of  this  course  is  to  provide  a  student  with  knowledge  of  the  fundamental  concepts  and 
basic  understanding  of  the  data  structures  and  use  of  vector  product  format  The  discussions 
will  include  an  overview  of  the  VPF  georelational  model,  including  the  meaning  of  data 
objects,  data  operations,  and  data  rules  for  geographic  data  management,  analysis,  modeling, 
and  display. 

Module  3— Advanced  VPF  Training 

Course  1:  Advanced  VPF  Standard  and  Concepts.  The  goal  of  this  course  is  to  provide  a 
student  with  a  knowledge  of  advanced  VPF  concepts  and  use  and  manipulation  of  the  data 
structures  of  vector  product  format 

Course  2:  VPF  Database  Design.  The  goal  of  this  course  is  to  train  students  to  design 
databases  in  VPF,  and  to  create  a  VPF  database  design  that  may  be  generated  from  any  other 
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GIS  format  that  utilizes  the  georelational  model.  This  approach  does  not  incorporate  the  design 
of  any  other  GIS  table  formats. 

Module  4 — VPFVIEW  Application  Software 

This  module  teaches  the  VPFVIEW  system  architecture.  Topics  include  software  design  and 
documentation,  coding  philosophy,  the  philosophy  that  drives  specific  designs,  programming 
environment,  software  functionality,  data  flows,  and  data  structures  used  to  draw  features. 
Tools  from  the  VPFVIEW  toolbox  for  program  control  and  graphics,  file  interface,  system  and 
selection/queries,  and  menus  are  introduced.  The  principles  of  software  maintenance  are 
reviewed. 

Module  5 — VPF  Training  Seminar 

This  seminar  is  designed  for  advanced  technical  DMA  staff  with  experience  in  VPF  design  and 
structures.  A  list  of  topics  is  to  be  agreed  to  prior  to  the  beginning  of  this  seminar.  Topics  for 
the  seminar  will  be  a  subset  of  those  provided  in  Modules  2  and  3. 
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AML 

ANSI 

CAS 

CD-ROM 

CG 

CMAS 

DAFDF 

DCW 

DEM 

DGIWG 

DIGEST 

DLG 

DMA 

DMAAC 

DMASC 

DMI 

DNC 

DOD 

DPI 

DPS 

DTcD 

DXF 

EGA 

ESRI 

FACC 

FACD 

FACS 

FIPS 

GIS 

GUI 

JNC 

JOG 

LDSA 

NOAA 

NOS 

NOSC 

NRL 

ONC 

QA 

QC 

RAM 

RFC 

RGB 

RMS 


ARC  Macro  Language 

American  National  Standards  Institute 

Chicago  Aerial  Survey 

Compact  Disc-Read  Only  Memory 

City  Graphic 

Circular  Map  Accuracy  Standard 
Digital  Aeronautical  Flight  Information  File 
Digital  Chart  of  the  World 
Digital  Elevation  Model 

Digital  Geographic  Information  Working  Group 

Digital  Geographic  Information  Exchange  Standard 

Digital  Line  Growth 

Defense  Mapping  Agency 

Defense  Mapping  Agency  Aerospace  Center 

Defense  Mapping  Agency  Systems  Center 

Disc  Manufacturing,  Inc. 

Digital  Nautical  Chart 

Department  of  Defense 

Dots  Per  Inch 

Digital  Production  System 

Digital  Terrain  Elevation  Data 

Data  Exchange  Format 

Enhanced  Graphics  Adapter 

Environmental  Systems  Research  Institute,  Inc. 

Feature  Attribute  Coding  Catalogue 

Feature  Attribute  Coding  Dictionary 

Feature  Attribute  Coding  System 

Federal  Information  Processing  Standard 

Geographic  Information  System 

Graphical  User  Interface 

Jet  Navigation  Chart 

Joint  Operations  Graphic 

Loral  Defense  Systems — Akron 

National  Oceanographic  and  Atmospheric  Administration 

National  Ocean  Survey 

Naval  Ocean  Systems  Center 

Naval  Research  Laboratory 

Operational  Navigation  Chart 

Quality  Assurance 

Quality  Control 

Random  Access  Memory 

Request  for  Change 

Red,  Green,  Blue 

Root  Mean  Square 
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SCSI  Small  Computer  Standard  Interface 

SDTS  Spatial  Data  Transfer  Standard 

SML  Simple  Macro  Language 

SOP  Standard  Operating  Procedure 

SOW  Statement  of  Work 

SPCS  State  Plane  Coordinate  System 

SPTS  Spatial  Project  Tracking  System 

TIGER  Topologically  Integrated  Geographic  Encoding  and  Referencing  [System] 

TPC  Tactical  Pilotage  Chart 

USACE  United  States  Army  Corps  of  Engineers 

USGS  United  States  Geological  Survey 

VPF  Vector  Product  Format 

VPS  Vector  Product  Standard 

VRF  Vector  Relational  Format 

VSM  Vector  Smart  Map 
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Deliverables  associated  with  various  sections  of  this  report  are  listed  below  in  order  of 
discussion.  If  a  variety  of  interim  versions  of  a  particular  report  were  submitted,  only  the 
completed,  final  repeat  is  listed. 

Section  2.2.1:  Prototype  1  (12/19/89) 

Prototype  1  database  (on  floppy  disk) 

PC  ARC/INFO  software  and  licenses 
Evaluation  instructions 

Lithographic  maps  and  color  plots  of  the  database 

Section  2.2.2:  Prototype  2  (4/9/90) 

Prototype  2  database  (on  floppy  disk) 

Evaluation  instructions 

Lithographic  maps  and  color  plots  of  the  database 
Prototype  2  DCW  applications  software 

Section  2.2.3:  Prototype  3  (8/2/90) 

Prototype  3  database  (on  CD-ROM) 

Installation  instructions 
Evaluation  instructions 
Prototype  3  DCW  applications  software 

Section  2.2.4:  Prototype  4  (12/4/90) 

Prototype  4  database  (on  CD-ROM) 

Evaluation  instructions 

Lithographic  maps  and  color  plots  of  the  database 
Prototype  4  DCW  applications  software 
DCW  Users  Manual  (Prototype  4  Version) 
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Section  2.2.4:  DCW  Product  Specification 
DCW  Product  Specification  (10/21^1) 

Revised  DCW  Product  Specification  (Vegetation) — (12/4/91) 

Military  Specification — Digital  Chart  of  the  World  (DCW),  M3L-D-89009, 13  April  1992 

Section  2.3.1:  Aeronautical  Information  Study 
Aeronautical  Information  Study  (6/25/90) 

Section  2.3.2:  Elevation  Data  Study 
Elevation  Data  Study  (6/25/90) 

Section  2.3,3:  Tile  Design  Study 
Tile  Design  Study  (1 1/29/90) 

Section  2.3.4:  Indexing  Studies 

Indexing  Studies:  Coverage,  Thematic,  Gazetteer,  Spatial  Query  (2/27^1) 

Section  2.3.5:  Geographic  Organization  Study 
DCW  Geographic  Organization  (9/27/91) 

Section  2.3.6:  Symbolization  Study 
Symbolization  Study  (6/12/91) 

Section  2.3.7:  DCW  Error  Analysis  Study 
DCW  Error  Analysis  Study  (2/15/91) 

Section  2.4:  Vector  Product  Format  Military  Standard 
VPF  Military  Standard  (6/28/91) 

VPF  Military  Standard  Request  for  Change  (11/18/91) 

VPF  Military  Standard  (Version  0.8)  (3/5/92) 

Vector  Product  Format  Military  Standard,  MIL-STD-600006, 13  April  1992 
VPF  Design  Manual  (5/30/92) 
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Section  2.5:  VPFVIEW  Software  Development 
DCW  Application  Software  Report  (3/14/91) 

First  VPFVIEW-DOS  Software  Prototype  (5/24/91) 

Second  VPFVIEW-DOS  Software  Prototype  (10/14/91) 

VPFVIEW  -DOS  Functional  Description  (10/14/91) 

VPFVIEW-DOS  Functional  Test  Plan  (Parts  1  and  2)  (1/30/92) 
VPFVIEW  Users  Manual  for  the  DCW  ( 1/30/92) 

VPFVIEW-UNIX  Functional  Requirements  (3/16/92) 
VPFVIEW-DOS  Version  1.0  (3/30/92) 

VPFVIEW-DOS  Functional  Test  Report  (3/30/92) 

VFPVIEW-DOS  Applications  Software  Report  (4/16/92) 
VPFVIEW-DOS  Integration  Test  Report  (4/24/92) 

System  Design  Document  for  VPFVIEW-UNIX  (4/10/92) 

Detailed  Design  Document  for  VPFVIEW-UNIX  (4/29/92) 
VPFVFIEW-UNIX  (Alpha)  (6/26/92) 

VPFVIEW-UNIX — Multi-Library  Functional  Requirements  (7/2/92) 
VPFVIEW-UNIX— Multi-Library  Design  (7/17/92) 

VPFVIEW-UNIX — Multi-Database  Functional  Requirements  (9/4/92) 
VPFVIEW-UNIX— Multi-Database  System  Design  (9/4/92) 
VPFVIEW-UNLX— Multi-Database  Detailed  Design  (10/92  prop.) 
VPFVIEW-UNDC— Multi-Database  Version  1.0  (12/92,  prop.) 

Sections  3.1  through  3.8:  DCW  Production 
DCW  Production  Plan  (12/4/90) 

DCW  Standard  Operating  Procedures  (1/4/91) 

DCW  Package  Design  (3/14/91) 

Production  System  Description  (3/28/91) 

Revised  DCW  Standard  Operating  Procedures  (5/10/91) 

DCW  Standard  Operating  Procedures  Part  3  (10/5/91) 

Revised  DCW  Package  Design  (1 1/1 1/91) 

Revised  DCW  Standard  Operating  Procedures  (Vegetation)  (12/13/91) 
Final  DCW  Standard  Operating  Procedures  (1/15/92) 

DCW  CD-ROM  Preliminary  Disc  A  (1/30/92) 
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DCW  CD-ROM  Preliminary  Disc  B  (2/28/91) 

DCW  CD-ROM  Preliminary  Disc  C  (3/4/92) 

DCW  CD-ROM  Preliminary  Disc  D  (4/20/92) 

DCW  Sets  (Lot  1—150  Units)  to  DMA  (7/28/92) 

DCW  Sets  (Lot  2—1,500  Units)  to  USGS  (7/31/92) 

DCW  Sets  (Lot  2—3,000  Units)  to  DMA  (8/4/92) 

DCW  Sets  (Lot  3 — 1,850  Units)  to  United  Kingdom  (8/5/92) 

DCW  Sets  (Lot  3—3,000  Units)  to  Canada  (8/18/92) 

DCW  Sets  (Lot  3—500  Units)  to  Australia  (8/19/92) 

Section  3.9:  DCW  Quality  Assurance 
Quality  Assurance  Plan  (3/18/91) 

Section  3.10:  Desert  Shieid/Desert  Storm  Support 
Database  of  Kuwait  City  (10/20/90) 

Database  of  Baghdad  (10/18/90) 

Database  of  Persian  Gulf  (from  Joint  Operations  Graphics)  (12/17/90) 

Database  of  Persian  Gulf  (from  Tactical  Pilotage  Charts)  (12/17/90) 

ARC/INFO  data  dictionary  for  1 :250,000  digital  JOG 

Section  4.1:  Digital  Nautical  Chart  (DNC) 

DNC  Phase  1A:  Floppy  Disk  Data  Sampler  (1 1/22/91) 

DNC  Phase  IB:  Magnetic  Tape  Data  Sampler — Norfolk,  VA  (1/1592) 

DNC  Phase  2:  CD-ROM  data  sampler — Norfolk,  VA  (6/30/92) 

DNC  Phase  3:  CD-ROM  data  sampler — Norfolk,  VA  and  New  York,  NY  (1 1/92,  prop.) 
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Section  4.2:  Vector  Smart  Map  (VSM) 

Prototype  1  Medium-Resolution  VSM  Product  Specification  (10/92,  prop.) 
Prototype  1  High-Resolution  VSM  Product  Specification  (10/92,  prop.) 
Prototype  1  VSM  Database  (Texas  and  Bolivia)  (10/92,  prop.) 

Prototype  2  Medium-Resolution  VSM  Product  Specification  (1993,  prop.) 
Prototype  2  High-Resolution  VSM  Product  Specification  (1993,  prop.) 
Prototype  2  VSM  Database  (Texas  and  Bolivia)  (1993,  prop.) 

Other  Significant  Deliverables 

Configuration  Management  Plan  (2/23/90) 

DCW  Audio  Visual  Tape  (4/3/92) 

DCW  Training  Plan  (8/27^>) 

A R C/INFO- to-  VPF  Converter  Programmer  Documentation  (9/21/92) 
Development  of  the  DCW  (9/25/92) 
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